Re: Hungarian notation

[nreitzel@lonestar.jpl.utsa.edu (Norman L. Reitzel )]

In article <319D2278.3F9A@netonecom.net> Arne W Flones <flonesaw@netonecom.net> writes:
>mAg wrote:
>> 
>> Hungarian Notation is an excellent concept, but I am sure that it will be
>> appreciated only by the programmers who have to work with serious code and
>> maintain it for years. [snip]
>
>B.S!!  It is a b-a-a-a-a-a-d idea.  It is an idiotic coding standard.  In "Programming Pearls," 
>Jon Bentley tells us to debug the code, not the comments.  With Microsoft's idea, we now must 
>remember to debug the code, not the Hungarian Notation.  Hungarian notation is a horrible idea.  
>These kinds of standards are an attempt to make code readable when there are multiple 
>programmers.  Unfortunately, they never work.
>
>Case in point:  The first time somebody wants to change the type of an identifier and doesn't 
>want to grep through all the source code to find all uses of the variable, Hungarian Notation 
>stops working.  As is ALWAYS the case, this will happen, especially in a large project.
>
What's worse, Arne, somebody will change the type, say from szShortSTring 
to pszReallyLongString, find that it's referenced a zillion times, and 
"fix" it by changing the name BACK, and then changing some (but not all) 
of the context of the reference.  If we're lucky, the stuff left out is 
in a really well used chunk of code and breaks things immediately.  If 
not, we've turned a good piece of software into a crash waiting to happen.

Worse worse, the "p" thing.  I -HATE- (stronger word?) "p" variables.  I 
want to see every last dereference, not have them take place by default.  
I attribute about half of the reason Pascal programmers don't much use 
pointers to the fool notion that a "pointer to something" is not an 
abstract object in it's own right, and merely represents an alternate 
name for the original object.  I cannot conceive of a more error-prone 
concept than an "alternate name".

As for serious code, I've ported million line projects for a telephone 
company, and managed projects that produced twice that.  The key to 
maintainability is defensive programming, and ADEQUATE BLOCK COMMENTS.  
Any chunk of code that does not contain info about what it does and how 
it does it is an error waiting to happen.  The rude concept of 
"self-documenting" code belongs in an ivory tower with those who teach, 
not in the trenches with those of us who DO.



-- 
   Norman L. Reitzel, Jr.       |    "When you live beside the graveyard,
   nreitzel@lonestar.utsa.edu   |     you can't cry for every funeral."
   Blue Water Ventures, dba.    |                     Russian Proverb