Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I think the same goes for putting "m" or "g" or whatever in for member or 
>> global variables, etc.
> 
>   Why? When I started using those, my own code became much easier to
> understand to me months later.

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 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.

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.

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

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

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

For that matter, where in that chain would you find the static/global 
"NextDrawAction"?  (Hint, if you just think about what those names might be, 
(and knowing that "Boll" is my name for what MVC calls "Controller") there's 
really only two likely answers.)

> 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?

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"? Or click "Go to 
definition" to change the type?

Anyway, I'm not saying it's necessarily bad. For one thing, C doesn't let 
you invent your own scopes (static, global, member,auto, etc) etc, and 
people don't encode the visibility (public, protected, etc) in those names, 
so the likelihood of having to change from a function argument to a member 
variable, or from a global to an auto is very low.

The other problem with the hungarian stuff is that people will typedef 
things, so you have code like
     DRM_RESULT result = DO_SOME_DRM_CRAP(pszName, i32Size, ...)
Why does "result" not get a hungarian flag? What flag would you put there? 
The whole point of typedeffing DRM_RESULT is to abstract away the type.

As soon as you put hungarian on your variables, you've eliminated the 
benefit of typedefs to control the type, which is a far better way of doing it.

-- 
Darren New, San Diego CA, USA (PST)
    Eiffel - The language that lets you specify exactly
    that the code does what you think it does, even if
    it doesn't do what you wanted.

Post a reply to this message