Is there a standard acceptable convention for parameters in Java to straightforward constructors and setters?
(I've seen the answer for C++, but practices are often different between the two communities)
Suppose that I have a class C with a foo field.
I have commonly seen the following three options:
public C(Type foo_)
{
foo = foo_;
}
public void setFoo(Type foo_)
{
foo = foo_;
}
public C(Type foo)
{
this.foo = foo;
}
public void setFoo(Type foo)
{
this.foo = foo;
}
public C(Type bar)
{
this.foo = bar;
}
public void setFoo(Type bar)
{
this.foo = bar;
}
I tend to use 2, but I'm wondering what's correct practice.
While naming the constructor of a class in Java you need to keep the following points in mind. The name of the constructor should be the same (same case) as the class name (along with the access specifier). A constructor should not have any return type. Constructor cannot be static, final, abstract and, synchronized.
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).
Java uses CamelCase as a practice for writing names of methods, variables, classes, packages, and constants.
For variables, the Java naming convention is to always start with a lowercase letter and then capitalize the first letter of every subsequent word. Variables in Java are not allowed to contain white space, so variables made from compound words are to be written with a lower camel case syntax.
Option two is most common. In Java it's considered poor practice to use meaningless name prefixes or suffixes to distinguish instance variables from parameters from local variables. But there are no conventions for the names themselves. Use whatever names make the code easiest to understand.
I've also seen the Option 2 as the most common one:
int importance;
public int getImportance()
{
return importance;
}
public void setFoo(int importance)
{
this.importance = importance;
}
IDEs such as Eclipse and Netbeans will automatically write the getters and setters in the above format.
There are a few merits to using this method:
Does not use the underscore (_
) character in the field name -- underscores are not recommended for non-constant field names.
The use of the underscore character in an identifier is not recommended except for identifiers for constants.
The Variables page of The Java Tutorials mentions the following about underscores:
If your variable stores a constant value, such as
static final int
NUM_GEARS = 6
, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.
(Emphasis added.)
Since field names are not constants, according to what is written on that page, one should not use underscores in non-constant fields.
IDEs can automatically add Javadoc comments according to the name of the parameter of the method, so having the name of the field in the parameter list would be beneficial.
The following is an example of an automatically generated Javadoc:
/**
*
* @param importance <-- Parameter name in Javadoc matches
* the parameter name in the code.
*/
public void setImportance(int importance)
{
this.importance = importance;
}
Having the Javadoc reflect the name of the field has another benefit -- IDEs that have code completion can use the field name in the Javadoc in order to automatically fill out parameter names:
// Code completion gives the following:
this.getImportance(importance);
Giving meaning to the field name and parameter name will make it easier to understand what the parameter actually represents.
Those are some of the merits I can come up with at the moment, and I believe that it is most likely the most common way to naming parameters in Java.
(1) is very C/C++. Java doesn't tend to use leading underscores much.
I personally use (2) almost exclusively.
(3) is just making your life difficult because it can be hard to think of two meaningful yet concise names for the member and the parameter.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With