DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Hungarian naming convention

  1. #1
    Bob Rosen Guest

    Hungarian naming convention


    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 <>
    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 <>
    >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.


  2. #2
    Tim Patrick Guest

    Re: Hungarian naming convention

    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

Similar Threads

  1. Miltiple interfaces in Java and naming conflicts resolution
    By valentin in forum Architecture and Design
    Replies: 2
    Last Post: 09-05-2002, 07:45 AM
  2. Crazy naming convention
    By Michael Culley in forum .NET
    Replies: 32
    Last Post: 05-19-2002, 07:35 PM
  3. Cancer of the semicolon
    By John Proffitt in forum .NET
    Replies: 171
    Last Post: 03-07-2001, 09:00 PM
  4. Naming Convention for Javascript
    By YangYu in forum ASP.NET
    Replies: 0
    Last Post: 01-02-2001, 05:04 AM
  5. Naming Conventions
    By Jim Pragit in forum Java
    Replies: 2
    Last Post: 06-09-2000, 11:17 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
HTML5 Development Center
Latest Articles
Questions? Contact us.
Web Development
Latest Tips
Open Source

   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center