Roedy Green <roedy@mindprod.com> horrified us with:

No, I find the reverse convention far more confusing.  The "_" mutates the
parameter into something temporary.

I think you would hide the warts in the names, e.g.

getLastName();

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Not the way I do it.  I belong in the "accessor methods are evil" camp, so --
as far as I am concerned -- the relationship between a method name (or the name
of a getter/setter pair -- which is not the same as accessors) and the name of
any instance variable, is a matter of coincidence rather than convention.

So, in this case, I'd have methods:

   getLastName() { return m_lastName; }
   setLastName(String lastName) { m_lastName = lastName; }

OTOH I'd be just as happy with

   getLastName() { return m_names[m_names.length-1]; }
   setLastName(String lastName) { m_names[m_names.length-1] = lastName; }

Still, for those who do subscribe to the concept of "accessors", I see no
reason why the convention shouldn't allow one to drop the "m_" or "s_".

I don't like that at all, and I don't like reading code that does that.  The
prefixes are mucking up the readability of the most used variables.   Of
course, my "m_" prefix similarly mucks up the readability of the instance
variables, but since they are less "local" I think it's a worthwhile bargain.

BTW. the "_" in the prefix makes a big difference to my eyes --- I wouldn't
even *consider* using a prefix that wasn't set off in some way from the name
that it prefixed.

Better than a paintball session for building team spirit...

   -- chris

There is much in what you say.  (Though the XML weenies would probably jump on
it as another opportunity for XML-abuse...)

My main reservation is that it would be putting still more emphasis on the
*code* rather than on the *behaviour of the objects*, and that is a tendency
that I'd rather reverse than encourage.

IMO, Java IDEs (with the probable exception of BlueJ), and, in fact, the design
of Java itself*, foster a code-centric rather than object-centric way of
thinking.  That seems to lead some programmers to come up with very non-OO
designs; whereas, if they'd thinking objects rather than code, they would
likely have found much better designs.  (The purpose of OO being to achieve
good design, of course, not the other way around ;-).

(E.g: the recent thread about returning multiple objects from one method.)

   -- chris

[*] and it's going to get worse....

It is warning that you are assigning the instance variable isCalcRows to
itself. This has no effect as far as I am aware (is there some esoteric
thread/cpu-synchronisation issue that may involve this?)

The parameter iscalcRows is not actually used in the method. The IDE may
even warn about an unused parameter as well.

Peter

VisionSet <spam@ntlworld.com> horrified us with:

Sure, but isn't it clearer with a non-alphanumeric?

       isCalcRows = _isCalcRows;    // oooooo

vs.

       isCalcRows = theisCalcRows;    // bleahhhhhh