hungarian notation is evil (was Re: Do I always have to write "self." ?)

[Daley, MarkX]

Hmmm, sounds like reverse Polish notation to me.

- Mark

-----Original Message-----
From: jschmitt at vmlabs.com [mailto:jschmitt at vmlabs.com]
Sent: Thursday, May 04, 2000 1:42 AM
To: python-list at python.org
Subject: hungarian notation is evil (was Re: Do I always have to write
"self." ?)


Be forwarned, I have a particularly strong hate-on for hungarian
notation.  I think it is no coincidence that the worst software in the
world and the worst programming conventions come out of the same
establishment.

I have a bunch of philosophical reasons for disliking hungarian
notation, but I think the most basic is that it is the antithesis of
structured programming practices.  Two of these practices would be data
hiding and data abstraction.  Hungarian notation is directly at odds
with these ideals.  How can you have any level of abstraction if the
user of the abstraction has to be concerned with the minutia of the
implementation?  And, the very idea of hungarian notation is the exact
opposite of data hiding.

> > release.  Is it painful?  You bet.  Just ask Billy -- the
translation from
> > old symbol names to new names broke the compile for weeks.  But
once it was
> > all over, I had fixed no less than 14 bugs that would *never* become
> > apparent until after I'd released the code to the public.  Most of
the bugs
> > were bound to be of the "intermittent" type too, so I was
particularly
> > pleased at the end result.

If your problems are solved by this kind of mindless busy work, you
have much bigger problems that any amount of hungarian notation will
ever fix.  I good primer on writing maintainable code is recommended.
Try _Programming_with_Dick_and_Jane_.

> > Again, it takes skill to use a tool well.

What does it take to recognize such a mind-numbing productivity
inhibitor?  Hungarian notation is a stupid way to mask stupid
programming habits.  There's no need for it in any language, and in a
dynamically typed language like Python, it's even more sinful than in a
statically typed language such as C.


Just so there's no question about attributions, I'm enclosing the whole
message that I'm replying to.

In article <8el305$h77$1 at ites.inria.fr>,
  Cedric Adjih <adjih at inria..fr> wrote:
> Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote:
> > In article <8ehrb9$mm5$1 at ites.inria.fr>, Cedric Adjih wrote:
> >>  If you can read, you should be able to read the definition of
> >>any variable, and there are serious drawbacks. A flame of this
> >>notation is for instance in "Developing Windows NT Device Drivers":
> >>"The so-called `Hungarian Notation' (developped by a Hungarian
> >>programmer at Microsoft) is one of the worst ideas to have hit
> >>software development in many years"
>
> > "All good ideas are judged from the enemies they make." -- I forgot
who.
>
> >>  The main problem, is that when you change the type of a structure
> >>you _cannot_ change the name (because other people are using it),
> >>so the type specification becomes plain wrong. The 'wParam'
> >>is reported to be such an example (now unsigned 32 bits), there
> >>are other examples in Microsoft API (should be worse with Win64).
>
> > Hungarian notation is fine for the definition of an API, as long as
its used
> > to describe abstract concepts, like arrays, pointers to things, a
count of
> > whatever, etc.  Hardcoding the bit-widths of types is obviously
going to get
> > you into trouble in the future.  Just because Microsoft fscked up
the
> > execution doesn't mean the idea is somehow "bad."
>
> > Like I said earlier, I use it only when it makes *sense* to.  Like
anything
> > else you have in your toolshed, Hungarian notation is a tool.
Those who are
> > skilled in its use will not have the problems you cite above.  :)
Those who
> > aren't only use it because it's a fad.
>
>   It's ok. It's just that most of the time I've read some code using
it,
> it was following Microsoft broken conventions. I personally don't
> like marking pointers/arrays (he! that would be like Perl), but I
> using it in a clever way, is of course quite good.
>
> >>  Also each time you change the type of one variable/parameter,
> >>you have change all the variable names of all the code under
> >>your control.
>
> > In my work with Dolphin, I've found, on several occasions, where I
needed to
> > change symbol names pervasively throughout the source.  I have
found #MORE
> > BUGS# just waiting to crop up and bite me in the butt this way than
through
> > any other technique.  The very thing you cite as a "problem" is the
very
> > thing that will help reduce the number of bugs in Dolphin upon its
final
> > release.  Is it painful?  You bet.  Just ask Billy -- the
translation from
> > old symbol names to new names broke the compile for weeks.  But
once it was
> > all over, I had fixed no less than 14 bugs that would *never* become
> > apparent until after I'd released the code to the public.  Most of
the bugs
> > were bound to be of the "intermittent" type too, so I was
particularly
> > pleased at the end result.
> >
> > I view it as sheer laziness on the programmers part.  You get what
you pay
> > for.
>
>   That's right. This is why, when I change code and break some
> invariant/expectation (even if the types aren't changed), I often
> change the variable/struct/function names, to review all the code
> possibly using it.
>
> >>  And finally, for multi-platform code, it makes less sense:
> >>what happens if you don't have 2-bytes integers and you
> >>have code with wXXXX variables (unsigned int 16 bits) ?
>
> > On PowerPCs, a word is 32-bits.  On Intels, 16-bits.  So what's the
lesson
> > to be learned here?  Don't hardcode widths in the meanings of your
symbols.
>
> > Hungarian notation as used by Microsoft is by far NOT the only way
to use
> > it.
>
> No but the very name "Hungarian notation" comes from its (incorrect)
use
> at Microsoft.
>
> >     For example, I *never* identify word-widths in my Hungarian
notated
> > variable names.  Why?  Because of the very problem you cite above.
However,
> > I do indicate higher-level meanings with prefixes: p for pointer, c
for a
> > count (e.g., cb for a count of bytes, cuint32 for a count of 32-bit
unsigned
> > integers, etc), a for array, etc.
>
> > Again, it takes skill to use a tool well.
>
> Agreed.
>
> -- Cedric
>


Sent via Deja.com http://www.deja.com/
Before you buy.