Hungarian notation

Hungarian notation has had a fascinating history. Because I am still getting quite a few emails asking for details, history, or advice, I decided to sit down and write up some of the answers, even though Hungarian, on the face of it, has nothing to do with Intentional Software. So I am writing now as a private person but I would like to come back later with some interesting connections with intentionality.

It is a lot of fun to Google “Hungarian naming”. I get a particular kick out of this (scroll to #29 and #30) site but mostly the criticism is quite mild. Many people recognize that not all dialects have the original intent, and when the focus moved over to the implementation types – like short, int, or long – the conventions were less useful or even counterproductive. As we will see, the idea was really to distinguish types that are meaningful in the particular application, what we call application types.

I still have the listings of the program that started the whole thing – it was written in 1972 and 1973 while I was part-time employed at NASA Ames in Mountain View, Ca. (my other part times in those years were Xerox PARC and Stanford). The program, code named Peso, was a translator that inputted wiring diagrams and compiled special purpose simulators that could simulate the complex circuits so described, including the parallel simulation of simple failure modes of the circuits – this was at a time when complex circuits were indeed prone to failure and finding the failures was a practical problem.

Peso was written in PDP-10 machine code, which could be organized, with the help of macros and some discipline, as a simple programming language. As you might imagine, the program had to be quite complex. Among other things, we had:

• card numbers
• card types
• card pin numbers
• DIP (meaning microchip) positions on the card
• DIP types
• DIP pins
• DIP failure modes
• DIP type simulating methods
• signal names
• signal simulation variables

and their connections to each other. The machine had its own implementation types: words (36 bits BTW), half words, and general byte pointers, among others, with specific operations being valid for specific datatypes only – however there was no automatic checking of these rules whatsoever.

After only a few days of work I realized that I had to create an order in this potential chaos and that is how the naming conventions were first used. All the above quantities and formats got their “tags” and then all the related structures could be easily named and the code practically wrote itself.

Here are some comment lines from somewhere in the 1000 odd pages of the code (yes it was all upper case):

; IF LC=(CP), SCAN BACKPANEL WIRELIST AND FOR EVERY
; (CN, BWPN) FIND LC ON THAT CARD AND CALL PRPLC(LC, CN)

I can see that here a local signal (LC) on a card reaches the connector at card pin number CP which is connected through backplane wiring that was defined in terms of card numbers (CN) and BWPN’s (pin numbers on the backplane were numbered differently than on the card – ask the engineers why...) which allowed the signal to propagate to other cards, etc. And yes, the code ran very well, finding lots of faults first in the wirelists and then in the 1970 vintage supercomputer itself.

The next project using the conventions was Bravo, the first WYSIWYG editor at PARC for the Alto, which was the first personal computer. Bravo was written in BCPL which was just one step above machine code, since there was only one data-type: the 16 bit machine word. I remember many tags from Bravo, for example the easy-to-say letter combination CP from Peso was reused for “character pointer”.

In the early days of Application Software Development at Microsoft, we did not legislate the use of the conventions, but as the software got more sophisticated, its use spread rapidly. Now we were using C, where the pointer arithmetic, in particular, had to be done very carefully and with full understanding what the application types (such as character pointers in an editor) and the implementation types were. Mac Excel in particular, was a very demanding application, initially half interpreted, half machine coded, with GUI, and a complex spreadsheet recalculation engine. The hundreds of types would have been very difficult to keep track of without the conventions. This was also the time that Doug Klunder published his summary of the Hungarian naming convention.

It was probably Doug, ever fond of irony, who first called the conventions “Hungarian” – a combined reminder of my Hungarian origins and a twist on the phrase “it’s Greek to me” ironically implying that code using the conventions would not be very readable. The term stuck maybe because it followed the pattern of “Reverse Polish Notation”. Many years later I was approached by a researcher for the Oxford English Dictionary for documentation on the usage and origins. I have not seen the term in the OED yet, but it would fill me with immense pride if this idea appeared there as only the 3^rd sense of “Hungarian”.

With the diffusion of the GUI-experienced application programmers into the Windows development group, the naming conventions also spread and dialects inevitably appeared. Unfortunately one of the less attractive dialects got the largest circulation through Petzold’s excellent book on Windows programming. Since then a lot of things happened, the Web made it even easier for Hungarian to spread and mutate, and OOP has become universal which created counter pressure from other conventions, and also made some of the types part of the language (for example the Hungarian enumerated element coRed would be written in OOP as Co.Red, where Co could be the enumerated type.)

So much for the history. Now let’s look at some of the controversies.

You can probably guess how I feel about Hungarian: I am completely sold on it, all the code that my company now produces uses it internally, and I couldn’t live (OK, I could not program) without it. At the same time we recognize the resistance that it generates, one might say the “high activation energy” that is required, so we make sure that our API’s and publications do not depend on this.

If you read some of the above references, you are aware of the main goals of Hungarian, namely, that names be carriers of application type (as opposed to implementation type) information which then serves as an excellent mnemonic aid and thinking aid.

The most frequent issue with Hungarian is that it goes counter some well established and common sense ideas on naming, which are roughly the following:

a. Names should be descriptive, and as long as needed
    For example Font, Color, Window, Table, Red, CommonCacheForAuxiliaryFilePageTable etc. 

b. Words should follow in the same order as in grammatical
     English MyFont, LastElement, GetItem, InvalidateDependencyStructure

c. Abbreviations are to be avoided – words should be pronounceable without spelling out the letters

d. In general, program readability is very important.

But to me the question was always less “what the names should be?” but rather “what are the things that should be named?” When I look at problems this way, I see the need to name more and more things: for example in the Peso program the way the pins were numbered in the backplane (two columns of staggered wire-twist posts per board) and the way the pins are numbered on the card that plugs into the connector (one column of connectors on one side of the printed circuit board.) I would be dissatisfied by all of the obvious alternatives:

“they are all integers, call them, i, j , k; or pinInput, myPin, cardsPin etc.”

“describe them until you are satisfied: outputPinOnTheBackplane, pinNumberForTheBackplane, pinNumberOnTheCard”

Before we start choosing, we must realize that this is just the tip of this particular “pin number distinction” iceberg. We not only have to name a few fields or method parameters of this kind, but we will have a whole host of related entities. For example the various maps: the map from the backplane pin number to the backplane connections, or from the board pin to the printed circuit connections. If we have a variant record – a subclass if you will – we will have to name the variant having to do with the kind of pin. Again, the obvious alternatives can be very frustrating:

“these are special cases to this problem, to this domain, to this solution. You need to solve them one-by-one using your engineering education and talents.”

“they are all maps, call them myMap, mainMap, backplaneHashTable”

“just say what you want” I guess that would be “map from the pin number for the backplane to a handle to a set of wirelist connections”, but that is not a name.

The reason for the frustration is that this iceberg is just a small corner of a veritable Antarctic ice shelf with thousands of similar icebergs related in complex ways. If the problem had to do with just one rather simple distinction there would be no need to worry about naming; we talked about it long enough, even iCard and jBack would work just fine. So it is the context of larger problems and especially in the context of wishing to make finer distinctions that the classical naming rules can be and should be questioned.

Many comments on the web point out that such distinctions can be made by types, and particularly by classes that are effectively programmer-created types. That is true – with some reservations – but even then, the types or classes have to be named, and the naming issue remains.

I found the only way to create a map of the giant ice-shelf with the thousands of icebergs is to choose rather arbitrary short tags and combine them in consistent ways – in other words by using Hungarian.

Even today, I start each problem or subproblem by enumerating all the types, quantities, states, origins, units, meta-levels (meaning an entity vs. the description of an entity) and many other distinctions of interest and give them names. I do not mind changing names, I often do, but I can’t keep things straight unless I have some precise handle for them at all times. At this point I have not written a line of code yet, but I have already made more distinctions and introduced more names than most programmers would at this stage.

Are these distinctions real? Are they useful? They are certainly real, in that any correct implementation of the same problem will have implicitly incorporated them in some form: in part encoded in the execution trace, and in part encoded somehow in the fully qualified names that are used. I maintain that they are useful because in my case they already explicitly encoded in the initial, possibly incorrect implementation as well! This means that the distance from the initial implementation and the correct implementation can be very small! One can get to the correct results faster.

We all notice how modern type safety simplifies our work. I am saying that by making more and finer distinctions and making them explicit, we can go even further.

Would it help to enrich the type systems? It would not hurt, but again, the new distinctions would require new names, so unless we are careful, we would take on new burdens in order to get new benefits. It is better to get the benefits of finer type distinction without the burden of having to name and remember the names of new entities.

So what do people who do not use Hungarian do? Probably the most common thing in production code is to simply muddle through and treat each name as if it were one of the few in a small help-file example or homework problem and be defensible as such. The next level in engineering and in costs is to keep wider consistency within the project, which is not easy to do, but still stop at the edge of the distinction that the implementation language happens to support.

My favorite recent software horror story has to do with lack of such distinction – the Mars Orbiter that was lost because the measurement units were not indicated for a quantity. This is widely understood to be “documentation error” but I think if it were more common for the type systems (whether automatic or manual) to take units into account, problems like this would not happen. Another peculiar conclusion was to connect the problem to the “cheaper, faster” design philosophy that the Mars Orbiter project was developed under. This might be literally correct – if more money had been thrown at the project, the problem might have been found in time. But I think that better programming techniques are good not only for saving the rocket from blowing up, they are also good for saving the next test run from blowing up and therefore they make the software project “cheaper and faster”.

Why go beyond the language type system for type checking?

Programmers seem to loathe making distinctions that are not sanctioned by the implementation language. I believe there are two reasons for this. The first one is practical: In most languages the step from what is sanctioned and what is not is a pretty expensive one. So it is easy to go from int to float to double, but it is a much bigger step to go from double to a class, just to make a small distinction of coordinate origin or the measurement unit, for example. Here the implementation type distinction is sanctioned, the coordinate origin distinction is not, so a general purpose abstraction would have to be invoked for the purpose with relatively higher implementation costs – design, typing, debugging, and run-time costs. The second reason may be more psychological. Programmers trust the language designers (with a lot of encouragement from language designers and vendors) to choose the level of distinction that is proper. So what is not supported must be somehow beyond the pale, it would not be cricket to make a distinction in ways that is not in the “style” of the language.

The obverse of the coin is when the implementation forces the programmers – quite legitimately - to make some distinction they did not think of first. For example the same quantity may have to be kept in different formats for interfacing with fixed API’s, or when different code-bases are merged. Not being used to name distinctions, now the programmers have to – the compiler demands it. There is no argument with the compiler. This is where we start seeing some strange names even in the better engineered code bases. Names will be distorted with variant spellings, with abbreviations to refer to the alternatives.

Here my example is the use of “delegates” in C#. These are type-safe procedure pointers (with class capabilities) and perform a very important task. Unfortunately, for each use one needs to name a number of related quantities: the delegate type, the instance of the type, a definition of a procedure that matches the delegate type. The language does not consider this a problem. After all in the examples they can call these just A, B and C (or myDelegateType, myDelegateInstance, etc.) but that will hardly scale. Yet the programmer does not really care about this. The programmer cares about passing a comparison operation to a method and the name distinction should not be necessary.

We are not normally conscious of the fact that we do not use a different name for the definition of a method and the call of the same method: the syntax, the language makes the minute distinction between the meta-levels, the call or the definition automatically. This distinction is sanctioned by the language and does not create demands for extra names (some IDE’s actually make this distinction visible by varying the color of the name: the definition may be shown in a different color than the name at the call) On the other hand, the distinction between the delegate type, instance, and definition are not sanctioned by the language, so we are forced to give them different names – and we are not normally conscious of the fact that we are unnecessarily forced to do so.

So what is the deal with being arbitrary about the basic tags, like cp, cn, lc in the Peso program?

Making up such terms is not only cheap, it is actually a very good tradeoff:

First, there are just not enough short and meaningful words to use and tags have to be short to be composable. For the linguists out there: the Danish language, with 4 more written vowels in their alphabet than in English, is much richer in two letter words which makes Danish great for crossword puzzles or for Scrabble.

Even more interesting is the fact (or experience) that meaningful words can actually hinder communications about programs, because it can be frequently unclear if the conventional or the technical meaning is meant.

It is claimed that the learning process for new programmers is shorter if the terms are already familiar to them. This is also contrary to experience. Of course they would have a superficial “aha” reaction right away, but with the typical complexity of software the details may be partially in clash with their prior expectation. So they still have to make the mental distinction between “previous familiar term” vs. “current familiar term”. This does not seem that simple, plus, more importantly, it will not scale to thousands of current terms, these simply can not all be “already familiar”. Making just a few of them familiar is also bad – it creates an unnatural aura for the particular aspects with the familiar names – why are they distinguished? Now we have to remember which ones are distinguished and which ones have other names (as in which of the 50 hash tables is actually called “hashTable”).

Of course the use of familiar terms in explanations, discussions, metaphors, comments, or as the bases of the mnemonics is essential. On the other hand, a phrase such as “character pointer” should not be a name, it should be only a part of the mnemonic legend and the explanation, the name or tag should be “cp”. In fact it might be interesting to poll people what they think a “character pointer” really was in Bravo, beyond that it helped with pointing at characters in an editor? I will give the answer to the curious at the end of this blog entry so you can test your expectation or ESP. My point is that using the “familiar” or “descriptive” term CharacterPointer would not have been superior to cp, and the short tag cp made hundreds of name combinations practical, so in the balance cp is much better than CharacterPointer.

Why the strange word order: type first, discriminator second?

This is a peculiar rule of the Hungarian language: family name comes first, and given name second as in the Government forms: for example Bartok Bela or Liszt Ferenc. Seriously, this is important in part for the same reason that the Government has: to sort related names close to each other. I was recently in a museum looking at the original ID plate on an artifact saying: “Engine, Rocket, Liquid Propellant” which is an extreme example of this usage.

But the main reason for the Hungarian word order is to be able to parse the name quickly, at a glance, into a type tag and the discriminator. If the type is kept at the end of the word it is much harder to parse for informal type checking:

Compare for instance:

    xdLeft += dxdNext;     (good) vs.
    leftXd += nextDxd;     (bad).

    (BTW: dxd is a constructed type, the difference between xd’s, so it is legitimate to add them to an xd.)

Lately we have started to separate type tags in some compositions to make them more parsable, for example, we write mappings as mpcn_xd, where the _ signals the start of a new type tag for the scanning eye.

What about readability? Isn’t that the most important?

Readability is one of those opaque concepts that is always praised but seldom defined. In my experience one seldom “reads” even just a part of a program aloud; Of course it is very important to be able to speak about the program and its concepts in a precise and comfortable way, most frequently without the reference to the actual text on paper or the screen, as in a team discussion. For this, the existence of names is the key – and as I mentioned in the standard practice many concepts, states, meta-levels or types remain nameless so they always have to be circumscribed informally, which is far from easy, quick or reliable way of communicating. Also, the use of common terms for local (“parochial”) entities can be also very confusing – as when something is called a “hashTable”.

When programs are read for understanding, the quality that is needed should be called “transparency” more than readability. That is, can one perceive the structure and the underlying intentions? Comments, by themselves, are seldom the answer. If we do not have sufficient precision in names, or rather in the resolution among our concepts, we can not write precise comments either. With names we get resolution, we get transparency of meaning and structure, and the comments become less significant.

Short names are the key for showing structure. This is one reason that mathematicians and physicists almost always use very short names, including Greek, Hebrew, and even made-up letters like the ħ (h-bar) of quantum mechanics. Extraneous detail at the leaves hides the shape of the tree. Einstein, for example, created a special notation for tensor calculus (the Einstein summation convention) just so that the large Sigma summation signs could be omitted from the tensor equations that comprise the General Theory of Relativity. This way the relationships are easier to recognize and the formulas are easier to manipulate. The theory is complex enough without having to worry about the sigmas everywhere. This is also true for programming. There is no shame in using similar tricks for our more modest application problems. Of course by “short” names here we mean tags of 2 to 5 characters which compose into fully distinguished names of 10 or more characters since we need hundreds of basic tags and thousands of names and we have to balance the need to show structure with the need to show the intention (the application type) as well.

Aren’t Hungarian names hard to learn?

My experience has been that, on the average, they are easier to recall than “descriptive names” – and by average I mean that we have to test against the precise recall of hundreds of names. For approximate recall of a few names, familiar terms would win handily. The problem with familiar descriptive names is that there is no single way to describe something, so to help oneself to remember a name, it is not very helpful to know that the name was “descriptive”, we would have to also remember what the particular quality was described. In Hungarian, the quality is given: it is the type – the intentional type, the domain type, the application type. If I know that – meaning that I know it by name – I will have the name, or at least the family name of the quantity.

I may not remember all the type tags in the 30 year old Peso program, but with a few minutes of inspection, I will be familiar again with cn, cp, lc, and the others, and then I will be ready to recognize and recall hundreds of variables, fields, and methods with a precision that is sufficient to make repairs or additions.

 

Here is the solution to the “puzzle” above:

cp was a 16 bit unsigned integer, an abstract pointer to the n’th character in the current state of a document doc. Given doc and cp, there was a rather expensive operation to get a real pointer pch to the character in memory and many additional things that made the system flexible and efficient.

There are many more things to discuss about Hungarian, for example the use of the discriminators and type modifiers. These can be also standardized to a large extent, and can be of great help in writing and maintaining software. So I will return to this topic at a later time.

Comments

[Mike Lambert]

Hey Charles. Was good meeting and talking to you about IP in the dinner line a week ago. :)

Anyways, I've never been a big fan of hungarian notation in my own code (perhaps because I was working on smaller projects), but I appreciated its value when I finally understood the difference between compiler and application types some time back.

I did have a couple comments about the above. First, taking measurement units into account is a very important one. Perl has some third-party modules that both enforce and perform automatic conversions between types.
http://cpan.uwinnipeg.ca/dist/Data-Dimensions
http://cpan.uwinnipeg.ca/dist/Class-Measure

I'm not convinced that it's the job of the type system to enforce such constraints. Generally only one type applies to an expression, and supporting these things in the type system would cause an explosion in types due to the orthogonal nature of these constraints, as well as many people shoe-horning their constraints into types so that they can be statically checked. I think enforcing these constraints as part of a more global constraint system is a more promising avenue for exploration. People can write up constraints and have these types statically checked by the compiler independant of implementation type checking. (Type checking might feed into the constraint checker, depending on the level of type-safety the language is going for). But I imagine I'm preaching to the choir here. :)

Secondly, in the section on "Aren’t Hungarian names hard to learn?", I think a good analogy would be to the list of prefixes and suffixes in the English language. We know what -ate and -ion and -er and -ed, as well as pre- and post- and whatnot mean, and we know how to apply them as "types" which change the meaning (the grammatical form) of the underlying word in different ways. By learning this common set of prefixes and suffixes, we can then create new words with ease, easily understand new words we have not yet seen, and generally deal with complex language more easily in the long run. Might be a good analogy to use the next time you find yourself defending Hungarian notation. :)

[Dave Fowler]

I have been using in Oracle PL/SQL for years.

Hungerian works very well and make reading/ writing good descriptive code pleasant.

Reading non-hungerian code initially forces constant checking how the variables are typed.

[Robert]

As a programming .NET and Objective-C, I use hungarian notation to help me make the code self-documenting.

I'm surprised I don't see too many people vouching for the pro's of hungarian. Thank you for the wonderful article.