Name Arguments

What style do java people like for naming parameters to constructors? (Assuming you don't want to scare your colleagues by using ArgumentAccumulators.)

  public Person(String name) { this.name = name; } // ugly

  public Person(String newName) { name = newName; } // ugly

  public Person(String n) { name = n; } // ugly

  public Person(String name) { myName = name; } // ugly, and so are all its variants

Is there a good way to do this?

-- BenAveling

I'd go with the first one. As the argument name is "visible" to users of the class, priority should be given to having a good readable argument name. Any ugliness internal to the implementation is not a big deal.

The "newName" argument name might make sense for a setter method, but I wouldn't like it for a constructor.

"n" is too cryptic.

-- KrisJohnson

Agreed. I think best practice should be to prefix the parameter. And I think newX makes sense for setters. I've used anotherX for comparisons, for eg:

  public boolean matches(String anotherFirstname, String anotherSurname) {
return startsWith(this.firstName, anotherFirstname)
&& startsWith(this.surname, anotherSurname);
}

But... what prefix makes most sense to people for constructors?

The problem is that we have two variables that are pointing to the same thing. So they should have the same name, or at least, names that explain the difference, such as "anotherX" in the above example. Or "newX" for setters.

Somehow munging the name has appeal, for eg, using a synonym, or an abbreviation. But it is confusing, because how do you know which name means what? A prefix should make clear that both variables are the same thing and what the relationship between them is.

  public Person(String theName) { name = theName; } 

The above is ugly because "the" could equally well be added to the parameter or the member.

  public Person(String Name) { name = Name; }

This has the same problem plus it makes Name looks like a class.

I don't know what a good prefix for constructors would be. It's a pity there's no language support for such a common idiom. Eg:

  public Person(String := name, ... ) { ... } // implicitly set this.name=name after calling super()

-- BenAveling

I like (and use) the first option. I use it everywhere and so does everyone I code with. It's a common idiom and easy to understand. There's one good name for the thing and it's used everywhere. -- EricHodges

I do use this.name=name. I just don't like having two different variables with the same name, even if they are handles to the same object.

On the other hand, I don't have mental trouble with having different functions with the same name, because I think of them as different representations of the same behaviour.

I guess this is just another case of the same thing. The only difference is the need to be explicit about which instance is being used.

-- BenAveling

Agreed. I used to consistently use the second (I was concerned about confusion about the scoping rules), but the first is standard, and unambiguous. Not to mention, it doesn't pollute tools that extract information from the declared names with entries with unnecessary prefixes (tools which automatically suggest parameters based on the name and type, for instance). -- WilliamUnderwood

I use this.name=name too, the reason is that I use EclipseIde and I want that autocomplete to prompt "Person(name)" when I type new Person<ctrl-space>, and I usually use "name" for the variable I am going to pass to Person, so the auto-complete is correct automatically too. It will be confusing for callers if the prompt is "Person(newName)". -- OliverChung

With EclipseIde you can set it to warn about masked member variables, which is nice.

  Preferences->Java->compiler->style->Local variable hides another=warning.

Just don't tell it to complain about constructors and setters. (Which is what I did, getting a zillion warnings and starting this whole thread.)

It's interesting how much having these style issues flagged by the ide can improve the resulting code. -- BenA

---

Normally, when I code, I prefer to give "_" suffix to member variables to distinguish them from local variables. Once you start doing it, it goes a long way in increasing readability. E.g.

  public Person(String name) { name_ = name; }

-- VhIndukumar

---

You should definitely leave the input parameters unadorned, so the JavaDoc lists intuitive parameter names. I prefer m_name for an instance member variable and s_name for a static member variable, though some people will object to this mild version of HungarianNotation.

---

I've used each of these at one time or another. Each can make sense, even newName, since that describes what you're passing into the setter or constructor. I think this is one of those issues like tab spacing and brace placement. It really doesn't matter much which convention you choose, as long as you do it the same everywhere.