Hungarian naming convention

Tim,

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>
wrote:
>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
the
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
the
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
to
help us with. A C++ version of the problem might look like this:

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

private:
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
conflicts.

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
of
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
as
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
is
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.

--

I am in favor of the use of Hungarian Naming standards. But one problem with
the standards, which I do discuss in my book, is that the Hungarian "language"
comes in so many dialects. Still, this is only a problem if there is no
dictionary by which your standards can be referenced.

I inherited the modern method of Hungarian standards used by so many programmers,
that of using the data type to choose the prefix tag. Personally, I see
no problem with it. And I see no problem with using the method presented
in your post, that of using Hungarian standards that focus on the usage of
variables instead of the data types. The Hungarian standards exist to provide
consistency. When you approach a piece of software that uses Hungarian,
you know that there are some consistent meanings associated with the tags.
As long as these tags are documented and understood by the reader, then
they are useful.

As you probably know, the Hungarian prefixes you may see in Visual Basic
code do not match those prefixes used in C and C++, primarily because the
choice of data types varies between the languages. Also, different programmers
within Visual Basic may use variations of the Hungarian system. In my book,
I document a set of Hungarian prefixes. However, it is not essential that
you use my exact system; what I stress when listing the prefixes is that
you document the standards by which you name variables and other data elements.
If you sufficiently document your naming standards, you may choose to use
another set of prefixes. The essential idea in using Hungarian naming standards,
or any other naming standards, is that you use some standards.

In my book, I recommend that you use the "b" prefix for Boolean variables,
and I use this for all new projects. However, I work on several older projects
that use "bln" as the prefix for Boolean. It is not important that two particular
projects match, since the projects probably have nothing to do with each
other. What is important is that I document the standards by which I do
variable naming, and that I am consistent in adhering to those standards.
-----
Tim Patrick
tim@vbstyleguide.com