Re: An kind of member function name scope specification
On Apr 27, 2:50 pm, Martin Eisenberg <martin.eisenb...@udo.edu> wrote:
James Kanze wrote:
I like myBalance and balance, but it's really a matter of style.
(Except that a trailing underscore isn't very visible, and should
probably be avoided.)
Isn't leanness the point of the trailing-underscore convention? The
knowledge of what's "mine" is not usually that hard to track once you
have some idea of how a method operates (which is a prerequisite for
doing anything to it); at least in the code I mostly read, almost all
manipulated non-locals are members. So arguably the information
should be there but not in yer face.
The information is superfluous. The only justification for it
is that you have a poor naming convention, and end up with
parameters and member variables that would otherwise have the
same name. The use of a convention here is to create two
different, distinctive names, not to encode some
meta-information along the lines of Hungarian notation. And two
different, distinctive names should be visually different; when
you see the name used, you want to be able to immediately
recognize which object is being referred to.
Personally, I dislike any kind of prefix convention because it
obscures the beginning of tokens, the most salient visual cue
for word recognition. The obtrusion is grantedly slight but
constant -- though perhaps, being the kind that typos impress
themselves on before subheadings, I'm more susceptible to the
effect. I suppose the "m_" prefix minimizes this but a suffix
is still more pleasant.
The use of a prefix stems from the fact that in English,
qualifiers preceded the qualified. Thus, we say "my status" and
"initial status", and not "status my" and "status initial". So
the member variable becomes "myStatus" and the argument to the
constructor "initialStatus". (Variable names are qualified
nouns, remember.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34