I haven't seen your book, so I don't know your opinion of it. But I wonder
if you have any comments on the following message that I saw on a usenet
newsgroup a couple of months ago:

From: Jeffrey C. Dege <jdege@jdege.visi.com>
Subject: Re: Help Settle Hungarian Notation Argument - Should we use it?
Date: Thursday, July 13, 2000 2:03 PM

On Wed, 12 Jul 2000 20:59:11 -0400, Don Chambers <dchamber@mindspring.com>
>I have taken over an existing project and we are having problems with
>variable naming conventions. The main argument we are having now is
>weather or not we should use Hungarian Notation. I tend to think we
>should not use it and get to make the decision but I want to get as
>much input as possible. If I can see a use for it I would certainly
>use it.

Something I wrote a while ago on this issue:

Regarding Hungarian Notation.

Hungarian Notation was invented by Charles Simonyi, and was first described
in his doctoral thesis. His original idea was to name variables based on
their type, possibly followed by a qualifier, if several variables of the
same type were in scope. In his thesis, it is clear that by type he does
_not_ mean the fundamental data types provided by a language, but rather
logical sets of quantities that are used by the programmer.

Unfortunately, most programmers have been introduced to HN through its use
in Microsoft's Windows API. If the developers of that API actually read
Simonyi's thesis, they certainly misunderstood it. In the Windows API,
prefixes are assigned based on the fundamental data types, int, long,
double, etc., which is in direct opposition to what Simonyi had suggested.

One of the examples Simonyi uses is a color graphics program that has a set
of internal values that denote colors.

Simonyi would have us recognize that color was a type, and thus define a
prefix for that type. In his example, he uses "co".

When comparing a local variable containing a color to the manifest value
red, his code would resemble:

#define coRed 1
int co;

if (co == coRed) ...

In this case, the use of the "co" prefix tells us something useful, that
variable and the constant, despite being declared as ints, are actually
colors, and should be treated as such. The compiler can't catch misuse, but
the pattern makes it easier for the programmer to do so. If the code
assigned 42 to the variable co, the compiler wouldn't complain, but it would
be likely that a reviewing programmer would notice.

This sort of type mapping makes a great deal of sense in the C. In the
early days, C provided no facilities for creating user-defined types, and
this sort of "mental mapping" between physical and logical types was all
that was possible. Later versions of C added limited facilities to create
user-defined types. A more experienced C programmer, using these limited
facilities, might end up with:

typedef ColorEnum {coUnset, coRed, coBlue, coGreen} Color;
Color co;

if (co == coRed) ...

This doesn't provide better compile-time checking than the first, but by
declaring co as of type Color you've given the maintenance programmer a
better clue as to how it should be used, even if Color is simply an alias
for int, and the compiler can't catch misuse. Note that the use of the type
prefixes makes at least as much sense here as it did before.

Meanwhile, Microsoft's approach to HN would prefix color variables with 'i',
for the underlying base type, which provides no useful information at all.

int iRED = 1;
int iColor;

if (iColor == iRed) ...

In C++, on the other hand, we have much better tools for creating
user-defined types, and with properly organized code we can have the
compiler catch the sort of problems that the type prefixes were supposed
help us with. A C++ version of the problem might look like this:

Class Color
enum value {Unset, Red, Blue, Green};
Color(value theValue = Unset) { myValue = theValue; }

value myValue;

Color theColor;

if (backdropColor == Color::Red) ...

Given this code, if we try to assign anything other than another Color
object to a Color object, the compiler will complain. If we try to compare
a Color object to anything other than a Color object, the compiler will
complain. We don't need to encode type information in the variable names.
The physical type is the logical type, and the compiler will catch any

Even so, most OO programmers include logical type information in their
variable names. But with OO designs producing so many user-defined types,
attempting to define two-character abbreviations for them all is a hopeless
task. Most C++ programmers have, instead, adopted the Smalltalk practice
naming variables as adjectiveNoun, where Noun is the Class type. So a
variable that held a window's background color which Simonyi's would have
named coBackground, and which Microsoft would have named lBackground, a C++
programmer would be more likely to name as backgroundColor. This provides
_more_ type information than does Hungarian, not less. And it provides the
_right_ sort of type information, as Simonyi had recommended, and Microsoft
practice had not.

As for the fundamental datatypes provided by the language, they generally
don't become a problem. The scope within which they are used is limited
enough that there is almost never confusion regarding type. If, for
example, you have a variable called "age", and you start getting confused
to whether it is an int or a double, you are probably also confused as to
whether it represents age in years or age in seconds. If such confusion
starts to arise, it's time for a new class:

Duration myAge = Date::currentDate() - myBirthDate;
cout << "I am " << myAge.inYears() << " years old." << endl;

In this case, subtracting two Date objects returns a Duration object, that
provides methods for expressing the duration in a number of ways. There
no possibility of confusion as to whether the duration is stored as integer
containing seconds, a double containing years, or whatever.

Hungarian as originally proposed by Simonyi provided meaningful
information to the programmer in type-poor languages such as C.
Hungarian as practiced by Microsoft provides no meaningful information
at all. In either case, Hungarian provides insufficient information
for a type-rich language like C++ or SmallTalk.