OK, I officially hate it.

In this crap codebase, people used a bunch of hungarian notation, then 
changed types around without fixing all the names.

So we have bunches of declarations like
   char * ulXYZ;
   unsigned char ulPDQ;
   long* pszABC;

Gah. It's worse than useless noise. It's useless wrong noise, that even 
makes the useful noise suspect enough to be useless.

If your IDE isn't good enough to tell you the type of the variable, it's not 
good enough to help you rename it when you change the type.

I think the same goes for putting "m" or "g" or whatever in for member or 
global variables, etc.

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

Darren New wrote:
> OK, I officially hate it.
> 
> In this crap codebase, people used a bunch of hungarian notation, then 
> changed types around without fixing all the names.

Epic, epic failure.

Now I remember why I never liked the Hungarian notation - and I only 
ready about it!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

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. When I have code along the lines of:

    void Foo::doSomething()
    {
        mCounter += someValue;
    }

or:

    void Foo::doSomething()
    {
        gCounter += someValue;
    }

as opposed to:

    void Foo::doSomething()
    {
        counter += someValue;
    }

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, and in
the second one it's clear that it's not. In the third one it could be
anything.

-- 
                                                          - Warp

Post a reply to this message

On 5-6-2010 10:25, 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. When I have code along the lines of:
> 
>     void Foo::doSomething()
>     {
>         mCounter += someValue;
>     }
> 
> or:
> 
>     void Foo::doSomething()
>     {
>         gCounter += someValue;
>     }
> 
> as opposed to:
> 
>     void Foo::doSomething()
>     {
>         counter += someValue;
>     }
> 
> 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, and in
> the second one it's clear that it's not. In the third one it could be
> anything.
> 
The objection is not to hungarian notation per se*. It is about using it 
wrongly. Like any other method of (in-line) documentation, if it does 
not match the source it is worse than no documentation at all.

*) though there is the danger that using it without IDE support to 
enforce the correct use, will almost certainly lead to mismatches.

Post a reply to this message

andrel <byt### [at] gmailcom> wrote:
> The objection is not to hungarian notation per se*. It is about using it 
> wrongly.

  That kind of complaint seems kind of moot. Of course if you use any naming
convention wrongly, the code becomes crap. If I do this:

    int multiply(int x, int y)
    {
        return x + y;
    }

then that code is crap, of course. It uses the wrong name for what the
function is doing.

  Why object about wrong usage of hungarian notation in particular?

-- 
                                                          - Warp

Post a reply to this message

On 5-6-2010 16:24, Warp wrote:
> andrel <byt### [at] gmailcom> wrote:
>> The objection is not to hungarian notation per se*. It is about using it 
>> wrongly.
> 
>   That kind of complaint seems kind of moot. Of course if you use any naming
> convention wrongly, the code becomes crap. If I do this:
> 
>     int multiply(int x, int y)
>     {
>         return x + y;
>     }
> 
> then that code is crap, of course. It uses the wrong name for what the
> function is doing.
> 
>   Why object about wrong usage of hungarian notation in particular?

Darren seems to have found a nice collection of them that made his life 
a bit less enjoyable.

Post a reply to this message

Warp wrote:
>   Why object about wrong usage of hungarian notation in particular?

Because, as I said in the first post, the easiest way to maintain the 
hungarian notation correctly is to use an IDE sophisticated enough you don't 
need hungarian notation to start with.

It's the same reason people prefer "self-documenting code" over "comments". 
And the hungarian notation isn't generally useful enough (especially in 
something like C) to warrant going thru the code base to fix it by hand when 
you change a declaration.

To be fair, this is the first time I've seen this happen so blatently, but 
it's an excellent reason to avoid it in the future. :-)

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

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

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. When I have code along the lines of:
> 
>     void Foo::doSomething()
>     {
>         mCounter += someValue;
>     }

Oh, also, I'd write this as
   this.counter += someValue;

or
   Foo::Counter += someValue;

if I thought it needed disambiguation at a particular point.

I often see people do
   void SetStuff(int xxx, int yyy, char* zzz)
   {
      mXxx = xxx;
      mYyy = yyy;
      mZzz = zzz;
   }
where I would either do
   this.xxx =xxx;
or I'd give the arguments different names
   void SetStuff(int newXxx, int newYyy)
   {
     xxx = newXxx;
     yyy = newYyy;
   }

I suggested that to someone who was in the habit of putting m_ and g_ and 
such on the fronts of variables, and he started naming every argument with 
the word "new" on the front.  I don't think he got what I was saying.

The point is to give every variable, even arguments and autos, a name that 
indicates their function. Then I almost never need disambiguation.

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

Darren New wrote:
> Warp wrote:
>>   Why object about wrong usage of hungarian notation in particular?
> 
> Because, as I said in the first post, the easiest way to maintain the
> hungarian notation correctly is to use an IDE sophisticated enough you
> don't need hungarian notation to start with.

My IDE uses different colors for global variables and member variables.
No need for m_ or g_ if the colors say enough :)

Post a reply to this message