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