Re: Hungarian notation

[Dave Toland <det@platsol.com>]

slary61@maine.maine.edu wrote:
| dewar@cs.nyu.edu (Robert Dewar) wrote:
| > Hungarian notation is certainly a remarkable demonstration of how few people
| > have learned and understood data abstraction. What's most interesting is
| > how difficult it is for its advocates to see this point, but I suppose that
| > is not surprising. If you never understood what abstraction is about, then
| > of course adopting a notation that destroys it will not concern you.
| 
| Perhaps Bill Gates will be contacting you for that explanation.
| Although the examples you cite support your opinion, the bottom
| line is that some of the largest software developers in the world
| insist on code using Hungarian Notation.
| 
| Why?

Biggest or most doesn't necessarily mean correct.  Hungarian notation has some
advantages, but keep in mind it was developed for C, not C++.  C is a procedural
language, and programs written in it have long been plagued by problems with
mismatches of fundamental data types.  The addition of function prototypes to
the language did much to ameliorate the problem for call interfaces, except for
functions like printf for which compile time checking is not possible *in the
general case* (yes, I know gcc can check printf calls, but only because the compiler
has special knowledge of that runtime routine).  And prototypes can only diagnose
mismatches for invariant argument lists if they are consistently used.  ANSI C
only requires prototypes for variable argument list functions, and in fact a large
body of code cannot use prototypes without tedious macro magic because it must
compile on platforms for which ANSI compilers are not or were not available.
This is where Hungarian notation can help compensate for the failures of the
language.

But C++ is an object oriented language.  Despite its ancestry, its philosophy is
completely different than that of C.  One of the key principles is to hide the
implementation details of the data and to deal instead with the data's abstract
properties.  The very *last* thing you want to do in that paradigm is name your
variables in a way that emphasizes their underlying implementation.

As for me, I've been practicing data abstraction in my C coding for over ten years,
so I've held a certain distaste for Hungarian notation for all that time as well.
I am very aware of the shortcomings of C in terms of type checking, but rather than
constraining variable names, I have favored instead a liberal use of typedefs to
form abstract data types.  I still need to know the underlying types for some
purposes, such as displaying with the printf family, but I try to encapsulate
the code that knows the internal format as much as possible.  I try to minimize
the lifetime and scope of variables, and the longer the lifetime, the more careful
I am in the naming of the variable.  So "i" is an appropriate name for a variable
used an an index for a 3-line iteration, and "CurrentSourceFileInfo" is an
appropriate name for a global structure (if it really must be global) used for
all operations on the source file presently open.

Imposing arbitrary rules results in code every bit as opaque as without the rules.
Teaching good judgement results in maintainable code.  Informed peer review of
code can point out poor name selection and treat it as the defect that it is.

-- 
I protest!  I am *NOT* a Merry Man!
Dave Toland       Platinum Solutions, Inc.    det@platsol.com