Best practice for parameter naming in Java constructors and simple setters

Asked 2009-06-13T23:23:23.893

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:

1) Use the actual field name with an underscore:

public C(Type foo_)
{
   foo = foo_;
}

public void setFoo(Type foo_)
{
   foo = foo_;
}

2) Use the actual field name, just use "this" in setting:

public C(Type foo)
{
   this.foo = foo;
}
public void setFoo(Type foo)
{
   this.foo = foo;
}

3) Completely inconsistent things like:

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.

java naming

Edit Report

2 Answers

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 -- <

answered 2009-06-14T05:10:35.837

Option two.

If you see a "setFoo(String foo)" definition (e.g. in javadoc or hover) you would be reasonable to expect that the field "foo" is set to the value of the parameter "foo". Other names may require you to double check - e.g. would setName(String person) just set the name to person or would additional action be taken (look up the name in a table of persons etc)?.

The usual reason for not doing so is that you may accidentially write

... foo = foo;

instead of

this.foo = foo;

which is a self-assignment of the parameter not doing anything. Modern compilers catch this - modern IDE generates the "this.foo = foo" statement when creating a setter for a field.

In Eclipse you can create the getter and setter for a field, with Ctrl-1 when the cursor is located on the field in question.

answered 2009-06-14T11:12:34.440

Best practice for parameter naming in Java constructors and simple setters

1) Use the actual field name with an underscore:

2) Use the actual field name, just use "this" in setting:

3) Completely inconsistent things like:

2 Answers

Your Answer