Arguments in constructors matching fields

What is your opinion in arguments in constructors matching members as in the following example

public Join(final int parent, final TIntHashSet children) {
this.parent = parent;
this.children = children;
}


I find this annoying since I have to use this. and also some code review applications generate warnings.

-
I'm not sure if this question really fits on code review but I provided a response for it below anyway. –  greatwolf Jan 30 '11 at 23:53
This is something more for Programmers.SE than for here. –  Mark Loeser Jan 31 '11 at 0:20
I feel like the question is in scope for Code Review: is using the same name for arguments and members confusing? Is it readable? –  Eric Bréchemier Feb 1 '11 at 14:21

I've personally always found the _parent or Hungarian-notation letters at the beginning far uglier than just saying this. this is very straightforward, especially if somebody else is reading your code. If I inherit somebody else's code and they use _ I change it immediately.

-
I personally dislike identifiers that begin with _ as the rules in C++ for their usage are non trivial (OK its trivial if you know the rules, but most people don't). Though this question is about Java I use the same rule just to make code more consistent across languages. –  Loki Astari Jan 31 '11 at 2:11
What compiler diagnostics will be generated if the parameter is misspelled? If one calls the constructor parameter NewWhatevr then "Whatever = NewWhatever" will fail; if one calls it Whatevr, then "this.Whatevr = Whatever" will be legitimate but erroneous code. –  supercat Jan 31 '11 at 18:41

Personally I use the most natural names for member variables.
This is because these are the ones you are going to use the most often (thus I dislike the m_ prefix).

For things that are going to happen less often (like parameters in constructors) I shorten them or add p_ depending on context and which is the most appropriate.

I have found most Java coding standards I have encountered seem to prefer (in the constructor) the use of

this.member = member;


Personally I dislike this (but always stick to the coding standards) as it it feels more error prone. I like distinct names for all identifiers (overlapping names lead to easier mistakes). I also think that distinct identifiers make it easier to spot (for humans) trivial mistakes.

this.member = p_member;


Can't get that wrong as each identifier is unique.

-
+1 for following conventions of the language/community. When in Rome... –  Eric Bréchemier Feb 1 '11 at 14:24

If you have access to a copy of "Clean Code" it has a chapter called "Meaningful Names" that I agree with. Bottom line, your name should denote exactly what it is referring to. Creating an encoding for the name a la C++ only slows down reading and causes devs to mentally skip it anyways. Also, your ide, be it eclipse, emacs, etc. should provide highlighting that makes the difference between class variables and parameters distinct.

-

My take is that what you have should be the preferred way of doing things. First of all, the names of the input parameters are what will show up in javadocs, and therefore should not have any prefix or silly names that will make the javadocs cryptic. Second, if the input parameter names clearly define what the things are, then why name the global variables something else that will make the rest of the code less meaningful or more difficult to maintain? Third, the scope of the input parameters is so limited, that it seems to me that you would rarely find this to be error-prone, especially when simply initializing class data.

-
You have a valid point with names showing in java docs. –  Alexandru Feb 2 '11 at 12:20

If you're worried about typing the extra characters for this you can consider the coding style used in C++. To avoid ambiguity between class data and parameter's passed into a method I usually use one of the following naming conventions for data members: m_parent and m_children (prefix m indicates member), parent_ and children_, myParent and myChildren.

-
I will consider your ideas. Since I use this. mainly in constructor and setters I find it inconsistent with the rest of my code. –  Alexandru Jan 30 '11 at 23:55

I would start with your first instinct of giving them different names, but only if the different names make sense. No Hungarian Notation! (Learned what a mess that was recently. Why do so many style guides still recommend it?) I commonly use different names in situations like this

public Leaf(Color initialColor) {
color = initialColor;
}


If the two variables represent the same thing and have no other meaningful name, then the this keyword is the way to go.

-