naming convention for method arguments

[GoogleCodeExporter]

Philip:
My second quibble is that I find the use of parameter names like aContainer to 
be very distracting when reading your code.  Would you be willing to change 
parameter names to something a little less bothersome (like "container") in the 
future?  I would be happy to go through the code and change the ones that are 
there now.  

Richard:
I have the habit of naming arguments differently from member variables, so that 
I do not have to do a this.lala = lala and that I never get confused when I 
remove an argument and suddenly a member variable with the same name takes over 
without me noticing. I recently use the a* for arguments and non-prefixed for 
members. Before I have _* for members and non-prefixed arguments.

Original issue reported on code.google.com by pvogren@gmail.com on 30 Jun 2010 at 3:32

[GoogleCodeExporter]

In a perfect world we would follow the "composed method pattern" and there 
would be little need to worry about names that conflict simply because our code 
would be more straightforward.  We would also use a bug detection library which 
would alert us to these situations.  Regardless, I would prefer it that when I 
look at some code I can't tell whether I wrote it or not - i.e. all the code 
looks the same.  When I see "aJCas" my mind revolts and I have to work through 
the distraction (and the impulse to change the name.)  I know in the grand 
scheme of things its a trivial complaint but it would be nice if we could agree 
on a convention.

Original comment by pvogren@gmail.com on 30 Jun 2010 at 3:33

[GoogleCodeExporter]

For what little it matters, given my level of activity on this project, my 
brain also revolts at the "aJcas" convention.

Original comment by steven.b...@gmail.com on 30 Jun 2010 at 4:31

[GoogleCodeExporter]

but thanks for saying!  it makes me feel less of the whiny baby that I am.  ;)

Original comment by pvogren@gmail.com on 30 Jun 2010 at 5:42

[GoogleCodeExporter]

I've just looked up what this composed method pattern is and found this 
http://codebetter.com/blogs/jeremy.miller/archive/2006/12/03/Composed-Method-Pat
tern.aspx

I couldn't help to notice that the guy uses the "_"-on-members convention I had 
before I adopted the "a"-on-arguments convention. I cannot exactly remember why 
I switched - only that I used some tool which had oddities when I was using the 
"_" thing. I think it may even have been Eclipse at the time when I was 
generating getters and setters.

Anyway, I don't see how this pattern has anything to do with a convention that 
is trying to bring in a clean distinction between argument variable names and 
member variable names. 

Do you employ any particular convention to keep a distinction between member 
and argument variables in your codebases?

Original comment by richard.eckart on 30 Jun 2010 at 7:21

[GoogleCodeExporter]

well the pattern and the convention are unrelated except that to the extent 
that you have long, meandering methods that are hard to read it is much easier 
to introduce bugs such as the ones you are trying to avoid with the naming 
convention.  

I do not have a naming convention to distinguish between member and argument 
variables.  I try to be careful to use 'this' when appropriate.  

Probably the right answer is not to rely on careful coding or naming 
conventions but rather use FindBugs or something comparable to detect these 
sorts of problems.   

Original comment by pvogren@gmail.com on 30 Jun 2010 at 7:49

[GoogleCodeExporter]

I don't like "this". But I can try to not use the "a" convention for uimaFIT 
code. However, this is a setting I made in Eclipse also for my whole UIMA 
workspace, it might happen that the occasional "a" will slip in. (Btw: Eclipse 
-> Preferences -> Java -> Code Style is where you can configure all kinds of 
prefixes and suffixes.)

Original comment by richard.eckart on 30 Jun 2010 at 8:13

[GoogleCodeExporter]

I personally love "this". I use it all the time even when not strictly 
necessary because it makes it immediately clear to the reader that I'm 
modifying or using an instance variable. The reader can get some sense of this 
distinction depending on how their IDE highlights, but I find "this" just much 
easier to spot. But maybe I need to adjust my IDE highlighting settings. ;-)

Original comment by steven.b...@gmail.com on 30 Jun 2010 at 8:18

[GoogleCodeExporter]

The problem I have with "this" is that it is easy to miss this issue:

method(String lala) {
   this.lala = lala;
}

The method body is still valid if I remove the parameter lala:

method()
{
  this.lala = lala;
}

but it is now useless. If a method becomes longer and gets more parameters, 
this is an easy one to miss. Occasionally I got quite puzzled because of this 
and quickly adopted a naming convention to get out of this problem.

Original comment by richard.eckart on 30 Jun 2010 at 8:22

[GoogleCodeExporter]

Well, I think there are actually ways around this. E.g. yank the level of name 
shadowing up to "error" and also tell Eclipse to report an error when a member 
is not accessed through "this". I usually don't do that because I do not keep 
project-specific Java Compiler settings in Eclipse (because I have loooots of 
projects and would always need to keep those settings in sync) and I have a lot 
of code that is generated or beyond my control which Eclipse would complain 
horribly about with such settings. So I ended up with the naming convention 
being the lesser evil.

Original comment by richard.eckart on 30 Jun 2010 at 8:26

[GoogleCodeExporter]

I generally think that argument names should be different than member variable 
names excepting those for setters and constructors in which case I think it is 
perfectly fine for them to be the same.  As it turns out you can set the 
compiler warning/error settings to flag for all name shadowing except these two 
cases.  So, I would vote for doing this.  I see this generates a quite a few 
warnings in uimaFIT (a lot more in ClearTK).  

So, if you are willing to drop the "a" prefix, then I will look into running 
FindBugs against this project.  I bet there is a way to work it into the maven 
build cycle and have it fail if certain kinds of buggy symptoms show up.  

Original comment by pvogren@gmail.com on 1 Jul 2010 at 2:56

[GoogleCodeExporter]

sorry - I misspoke.  I was just reminded of what you said about generated code 
because the jcasgen code generates warnings.  lame.

Original comment by pvogren@gmail.com on 1 Jul 2010 at 3:04

[GoogleCodeExporter]

I committed changes to several files submitted by Richard renaming argument 
variables minus the "a" prefix.  I will add another issue for running FindBugs.

Original comment by pvogren@gmail.com on 2 Jul 2010 at 4:37

• Changed state: Fixed