|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |