I want to create a package named form validator.
Is it better to write
form_validator,
formValidator or
formvalidator?
I want to mention that I want to avoid form.validator. And that form-validator is forbidden.
From the documentation on package naming convention:
Package names are written in all lower case to avoid conflict with the names of classes or interfaces
So this would leave you with the following two possibilities:
form_validator
formvalidator
Actually the documentation also makes it clear that underscore plays a special role when it appears in package names:
if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as "int" ... the suggested convention is to add an underscore.
So, underscore is suggested only in special cases, into which your naming problem does not seem to fall. So I would recommend formvalidator as the package name.
The most conventional one would be the 3rd one: formvalidator.
The Google Java Style guide notes:
5.2.1 Package names
Package names are all lowercase, with consecutive words simply concatenated together (no underscores). For example, com.example.deepspace, not com.example.deepSpace or com.example.deep_space.
As #teppic said, the Oracle Java Docs state that
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
In Java package names are written in all lower case. Which means following would be the most ideal packaging name.
formvalidator
This is also accepted.
form_validator
Package names are written in all lower case to avoid conflict with the names of classes or interfaces. So
form_validator or
formvalidator.
For details see here.
Related
How do you name a class when it's all caps in Java? For example, if I want to create a class to select certain people to be VIP. Should I name the class "VIPSelector" or "VipSelector"?
Thanks!
Both of your options work. The main goal with classes is to have them start with an Upper Case. So, VIPSelector and VipSelector both work. This convention is mostly used to get rid of a common mistake that you can find in OOP which is when you can't make the difference between a class and a method.
Imagine having a class object called "student", to initiate it, it would be
student s = new student();
That looks a lot like a method and this is why, by convention, we put the first letter in upper case.
This is how class Name should be :
Class names should be nouns, in mixed case with the first letter of
each internal word capitalized. Try to keep your class names simple
and descriptive. Use whole words-avoid acronyms and abbreviations
(unless the abbreviation is much more widely used than the long form,
such as URL or HTML).
Examples: class Raster; class ImageSprite;
Check this for the information : https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html#:~:text=Class%20names%20should%20be%20nouns,such%20as%20URL%20or%20HTML).
Both names are acceptable. The general convention for naming classes in Java is just that the first letter should always be capitalized and the whole name should be in camel case, meaning that the first letter of each word is capitalized.
The google style guide prefers VipSelector
See this answer to a similar question.
What should we expect from the following name? : mGage Program
if I camelCase this it will be mGageProgram and if I generate (in eclipse) the getters and setters I will get the following:
public String getmGageProgram() {
return mGageProgram;
}
public void setmGageProgram(String mGageProgram) {
this.mGageProgram = mGageProgram;
}
Which to me doesn't seem right as I was expecting the getMGageProgram() and setMGageProgram(value).
Are these getters/setters names alright?
According to 8.8: Capitalization of inferred names of the JavaBeans API specification
the names generated from the IDE are correct.
they are 100% correct :) but conventions differ among programmers , for me its method names in camel casing not variables. as for syntax its correct :)
I’d like to provide just a little more depth on what the spec says. It specifies how we get from the name of a getter and/or a setter to a property name. The interesting quote in this context is:
… to support the occasional use of all upper-case names, we check if
the first two characters of the name are both upper case and if so
leave it alone.
It’s from section 8.8: Capitalization of inferred names.
One example given is that URL (as in getURL or setURL) becomes (or stays) URL (not uRL).
So the method names that you and I would have expected, getMGageProgram and setMGageProgram, would have implied a property named MGageProgram with an upper case M. Since we wanted mGageProgram we need to use lower case m in the names of the getter and the setter.
The rules as I read them thus really allow you to use a lowercase letter right after get or set in any getter or setter name. This came as a peculiar surprise to me. Of course it’s not an option that we want to exploit in cases where we don’t have to.
Link: JavaBeans Spec download page
After reading the question Java packages com and org and answers, I am still curious:
Is there some strict rule that I can use only com edu and org?
And, is it bad idea to create package starting with something else than this?
Say, I am fro, Czech Republic and I own PavelJanicek company, can I create package which would be imported like
import cz.paveljanicek.usable.awesomeutils;
edit: Since one of answers supposes it should be possible, can I apply it also to new domain TLDs?
example:
import berlin.berlincity.touristguide.api;
A package name is defined by the language specification as a succession of valid identifiers, separated by ..
So the convention (for unicity purposes) is to use your domain name but any valid identifier can be used. This is a valid package name too:
é.è.û.¥
You should check out this link: Java Packages and Java Package namings
You should also look at similar topic
At last a quote to add:
If you're just doing personal projects where nobody else will use the code, then you can make up a package name that you like. Don't
make up something that starts with com. or net. or other top-level
domain though, because that would imply that you own the domain name
(ie. using com.john as your package name just because your name
happens to be John is not a good idea).
If you're going to give the code to anybody else, you should use a
globally unique package name, which according to Java conventions
means you should register and use a domain name.
Short: Use whatever you like :)
yes, that's the way you have to do if you own paveljanicek.
there are a lot of 'com' and 'org', but you can find many others;
for example, logback logging library contains classes in package
ch.qos.logback....
You can use whatever you want just honoring the Java limitations for identifiers.
Said that, usually is safe using Java conventions, but killerapp.gui.Main is a valid class identifier
You missed a lot of the information given in the answer. Here once again a snipped of what Sun defined:
The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.
Today we have even more top-level domains. The important part is to choose the domain you own in reverse order. I suggest you should read the answer once again, slowly. The goal is to avoid naming conflicts by choosing unique namespaces. And because domain names are already owned by a single company / person, they are good candidates to choose.
Is there a way to use a shortened package name in Java if you have conflicting names?
For instance, instead of typing out com.domain.a.b, if the conflict is in com.domain.a, you can just say b.SomeClass instead of com.domain.a.b.SomeClass. C# has a feature similar to this.
No, you either use fully qualified names or short names. You're probably looking for obscuring
A simple name may occur in contexts where it may potentially be
interpreted as the name of a variable, a type, or a package. In these
situations, the rules of §6.5 specify that a variable will be chosen
in preference to a type, and that a type will be chosen in preference
to a package. Thus, it is may sometimes be impossible to refer to a
visible type or package declaration via its simple name. We say that
such a declaration is obscured.
If you follow Java naming conventions, you shouldn't really have any issues.
This answer to another questions suggests, as a workaround for finding anonymous classes via reflection, to simply try all names, starting with ...$1 and counting up until no more can be found. Is this guaranteed to find all inner classes, or could there be cases where they start at 0 or some numbers are left out (for whatever reason)?
The JLS 13.1 specifies:
The class or interface must be named by its binary name, which must meet the following constraints:
The binary name of a top level type (§7.6) is its canonical name (§6.7).
[...]
The binary name of an anonymous class (§15.9.5) consists of the binary name of its immediately enclosing type, followed by $, followed by a non-empty sequence of digits.
So in theory, it does not have to start at 1, but it has to be something like EnclosingClass$N where N is a number.
According to this answer:
Note that the exact name of the files holding anonymous inner classes
is not standardized and might vary. But in practice I've yet to see
any other scheme than the one described here.
So I guess there is no such guarantee.
In this link to a java.sun.com tutorial, it explains anonymous classes from page 243 with example outputs which follow the naming convention described.e.g. *$1.class, *$2.class etc. On the top of page 246 it says:
The names of the anonymous classes at runtime are also shown in the program output. They are also the names used to designate their respective class files. Anonymous classes are not so anonymous after all.
Considering that this tutorial is on the Oracle website, It's almost certain that this is a convention that will not vary. Hope this helps :)