Darren New <dne### [at] sanrrcom> wrote:
> For the same reason. When you move it from being a member variable to a 
> function argument, or from a private member variable to a protected member 
> variable or a public member variable, you have to go and find and rename 
> them. And most of the time, it's visual noise.

  I have never understood this obsession some people have with "visual
noise". It seems that anything that exist to make a name more unambiguous
is always classified as "useless visual noise".

  Something is "visual noise" when it makes the code *harder* to read
because the "noise" is interfering with your capability of easily
understanding the code.

  Something which in some situations might not convey any additional
information to you is not "visual noise". You might use the word "redundant"
in the sense that it conveys the same information in more than one way (at
least in the context in question), but that's completely different from
"noise", which is something that is disruptive and makes it more difficult
to get the actual information.

  For example, you might have something like this:

    int Point::getX() { return x; }

  If you follow a naming pattern like being discussed here, it might instead
look like:

    int Point::getX() { return mX; }

  That's not "visual noise". It's not any harder to read and understand. You
might call it "redundant" (at least in this specific context, as the function
is so short and straightforward), and that's fine, but it's not "noise".

  You could even have it like this:

    int Point::getX() { return this->mX; }

  Now it's doubly-redundant because the same information (ie. that 'mX' is
a member variable of Point) is basically told three times, but it's still
not "visual noise". It's still pretty clear, readable and easy to understand.

  Where the 'm' prefixes start helping is when you have much more complicated
member functions which refer to local variables, function parameters, global
variables and member variables, especially when the names of the variables
are much less obvious.

> I far, far prefer taking the 10 seconds at the start to come up with an 
> unambiguous name that is clear how global the variable is.

  A common naming convention makes it much easier and unambiguous. Readers
don't have to start guessing if it's really a global variable or not.

> Maybe prefixing something with "g" to mean global (altho "s" to be static 
> might be better?;-) makes some sense, if your program has maybe two or three 
> actual globals. But for member variables vs arguments vs locals? No, that's 
> all right in front of you.

  There may be dozens of member variables, and the place where the member
variables are declared may be far away from the place where they are used
(they may even be in a completely different file). Seeing right away when
a variable is a member helps understanding such code.

> And "mCounter" is a member variable of... what class?

  If it's written as-is, without any reference or qualification, it's rather
obviously a member of 'this' (or whatever your language might call it). If
it has a reference or qualification, then it's obviously a member of that
class. One ought to know which class' member function one is reading and
trying to understand.

  And since member variables are never in the public or protected parts of
classes, there can be no ambiguous usage in a derived class member function.

  (Yes, I know some people put them in the public part of their classes,
and then write derived classes which refer to them directly without any
qualifications. But these are the same people who would use hungarian
notation in the wrong way, etc. Bad code is always bad code.)

> I have

> GameComponent -> DrawableGameComponent -> Boll -> StackableBoll -> 
> StackableScreen -> UIScreen -> MenuScreen -> OptionScreen -> PlayOptionScreen.

> Where in that chain would something as poorly named as "mCounter" be found? :-)

  Which class' member function are you reading? If it's an unqualified use,
it's a member of that class. (If it isn't, then you have breached good OOP
guidelines.)

> For that matter, where in that chain would you find the static/global 
> "NextDrawAction"?

  Same thing as with member variables.

> > the first two are much clearer than the third one. The third one doesn't
> > make it clear at all where 'counter' might be defined, while in the first
> > example it's clear that it's a member variable of the Foo class,

> Is it? Or is it a member variable of a base class of the Foo class?

  If it's a member variable of the base class, then the OO design is crappy.
No member variables in the public (or protected) interface.

> Why would I do that, when I can hover the mouse over the name and have it 
> come up and say "int Bar::Counter instance variable"?

  You don't realize that you are actually acknowleding the problem: You
acknowledge that if the name of the variable is so ambiguous, you need a
specialized program to tell you where it might be defined because otherwise
it's very difficult to know. Hence the name is ambiguous, and it's not
possible to easily know what it's referring to unless you do some research
or use some program to find the declaration.

  "I just use an IDE to tell me" is not a solution. It's an acknowledgement
that there is a problem.

-- 
                                                          - Warp

Post a reply to this message