Hungarian Notation

My dad always used to say, “Call me anything you want. Just don’t call me late for dinner.” If variables and functions in computer programs were sentient beings, I wonder if they’d say the same thing. As religious wars go among computer programmers, wars over naming conventions rank right up there with wars over favorite programming languages and favorite text editors.

Over the years, I’ve grown accustomed to various flame wars, and generally steer clear. But when I see flame wars over Hungarian Notation, I want to scream. You see, there are really two distinct naming conventions known as Hungarian Notation. I like to refer to them as Hungarian Notation and Anti-Hungarian Notation. The participants in these flame wars think they’re talking about Hungarian Notation, but they’re really flaming over Anti-Hungarian Notation. And that’s why I want to scream.

The difference between HN and A-HN is the story of two Charles’—Charles Simonyi and Charles Petzold. While I’m fairly versed in the Charles Simonyi story, I really have little knowledge of how the naming convention that Charles Simonyi outlined in his original paper metamorphosed into the naming convention that Charles Petzold described in Programming Windows. Perhaps Raymond Chen can fill us in on the details. They are, no doubt, sordid.

Whatever the details, they quite likely involve a misunderstanding fostered by an unfortunate choice of wording in Simonyi’s original paper. Not really Simony’s fault. After all, his native language is Hungarian, not English. While Simony talked about the “type” of a variable, he clearly wasn’t talking about the underlying language type of a given variable. He was talking about “type” in the sense of the operations that can be performed on a given variable. I like to refer to Simonyi’s concept of “type” as the “functional type” of a variable, as opposed to the variable’s “language type” as is often meant when people use the word “type” in conjunction with Hungarian Notation.

As Simonyi points out, a program written in C might have a function called, Position(int x, int y). The variables x and y, which both have an underlying language type of int, may well have distinctly different functional types. If x and y represent different dimensions in coordinate space, for example, it wouldn’t make sense to write, Position(y, x). The point, however, is that the variable names, x and y, conform to Simonyi-style Hungarian Notation.

Now, one way to metamorphose from Simonyi-style HN to Petzold-style HN, is to create unique user-defined language types for distinct functional types. In the above example, one might well say:

typedef int X;

typedef int Y;

void Position(X x, Y y);

Using this technique, we can maintain a one-to-one correspondence between the language type and the functional type, with the added benefit of being able to change the actual underlying language type of variables with functional types X and Y without having to perform a massive search/replace through all the code.

The one thing that Simonyi-style HN would not countenance would be the A-HN form of Position(int iX, int iY), because the “i” prefix doesn’t tell us anything about how iX and iY are used. It’s pointless information—decorations added by someone who really doesn’t understand the point of Simonyi-style HN.

For those of us who have grown accustomed to Simonyi-style HN, the whole “i” means “int” prefix thing is doubly horrible, because the “i” prefix in Simonyi-style HN is commonly understood to be an index into an array. If I put a character into an int, I’m not going to call it iCh. I’m just going to call it ch. To me, an ich is an index to a character in an array of characters.

Now, I’m a Word guy. Word has device-independent layout, where text layout is done in a coordinate space based on the design units of the font, which means that we often have to convert between layout coordinates and window coordinates. Being able to type XwFromXl sure beats the pants off having to type something like HorizLayCoordToHorizWinCoord.

But, I’m not here to add to the flame war. I’m just trying to correct a wrong that’s been allowed to fester for far too long. And, no, don’t get me started on MFC. Let’s just say that a good number of people who managed to not understand Charles Simonyi’s original paper happened to work at Microsoft.

So, now the .NET guidelines are steering people away from using Hungarian Notation, or more accurately Anti-Hungarian Notation, quite likely because it’s too late to correct years of bad practices. Better to just cut one’s losses. That’s something of a shame, because Simonyi-style Hungarian Notation was the basis leading a certain Excel developer to devise such function names as CleanPots and FreePot (a POT being a “piece ‘o’ text”).



Comments (10)

  1. David Cumps says:

    how about, intX and intY? no more "i" 😉

  2. Raymond Chen says:

    I think you nailed it, Rick. People misunderstood Simonyi-style HN; in particular, it appears that Petzold did and popularized it though his books. So now everybody’s primary exposure to HN is the Petzold style instead of the classic Simonyi style. And I don’t blame them for hating it.

    It’s Gresham’s law: Bad drives out good.

  3. Larry Osterman says:

    The other thing to keep in mind is the difference between "Apps" hungarian and "Systems" hungarian. Apps hungarian (also known as Klunder hungarian) is the brand of hungarian in Doug Klunder’s hungarian naming convention memo. This is pretty close to the pure Simonyi hungarian (although the Klunder memo isn’t clear if the prefix represents the type or the usage of a variable (consider a char * that’s used as an array of characters – is it a sz or is it an rgch?).

    Systems hungarian (also known as Ludwig hungarian) is the hungarian that the User team (led by Scott Ludwig) in Windows adopted for Windows 3.1. That’s the brand of hungarian that’s used for many of the Windows headers, and is used for Petzolds book. Systems hungarian is where you get wparam and lparam.

    It’s not surprising that when Dave Cutler ran into Hungarian for the first time he declared it an abomination and banned it from the NT tree.

    Personally, I prefer Klunder’s hungarian (with some modifications since Doug’s paper’s from 1989ish, and predates C++).

  4. Rick Schaut says:

    Someone misrepresenting himself as an emplyee of Microsoft wrote:

    "Hungarian is only a kludge for the development environment.

    "Now we have Intellisense, HN makes code like VB and COBOL, UNREADABLE due to the spam of TLAs.

    "For unmanaged code its pretty accepted to use HN but nowdays with better IDEs I now dont see the need. HN also gets in the way of well known terms, or formulas.

    "Can you imagine C = A+B becoming iC = iA+iB, or worse. it starts to lose its meaning for those well known terms. I sit down in the debugger with non developers for specalist implementations of formulas etc and HN is a no no there.

    "HN is dead.

    "Preprocessor DEFINES_BLAH_BLAH and MACROS_BLAH_BLAH along with HN are DEAD. They are a relic of the past and should be put to rest even in C/C++ and other unmanaged codebases.

    "Kill it."

    He later added the following:

    "Why not use camelCase and PascalCase as you would on C# in C/C++ ?

    "Both have the same issues for language maintainability and readability, there is no difference, we have to cast in both languages. They are both type based languages.

    "Look at camelCase/PascalCase code readability compared to HN code.

    "HUGE difference. How often have you look at C++ code and just scratched your head trying to fight through the prefixes, macros and defines to see the actual REAL solution its implementing."

    Due to this individual’s misrepresentation of his identity, I’ve deleted the original entries, but requote them here to preserve the substance of his remarks.

  5. Brad Abrams says:

    The .NET Guidelines you reference only talk about publicly exposed surface area… what you do in your own code is up to you… I choose not to fight that battle.. 🙂

  6. Kiliman says:

    Considering that Petzold has had a lot of influence on Windows developers over the years, I was curious as to what he’s been up to lately.

    Curiously, I haven’t found any blogs or other writings that are recent. His website hasn’t been updated in a while.

    I downloaded the companion code from his book "Programming in the Key of C#". Not surprisingly, he continues his use of A-HN in the sample code (sorry for bad formatting):

    static void DisplayLine(int i)


    const int iWidth = 60;

    string strDots = new string(‘.’,

    iWidth – (i + 1).ToString().Length

    – astrChapter[i].Length

    – aiPageNumber[i].ToString().Length);

    Console.WriteLine("{0}. {1}{2}{3}",

    i + 1, astrChapter[i], strDots, aiPageNumber[i]);


Skip to main content