A Better Notation for Naming
Back when Charles Symoni was at Xerox PARC, he had an interesting idea: add standard prefixes to the names used in computer programs to help readers quickly understand exactly what those names represent. This idea became known as Hungarian Notation, either because Symoni is himself Hungarian, or because the resulting names look pretty strange to the uninitiated.
This simple idea has been the topic of howling religious wars. If you don’t like Hungarian Notation, let me ask you: is it the idea of the notation that you think is bad, or is it some particular implementation of the idea that is bad? We’ll readily agree that some Hungarian dialects are counterproductive, demoralizing, or just plain awful. The dialect shown here is limited in what it attempts to accomplish, and it follows rules that are simple and strict. The result: it is easy to learn, and, once learned, it makes it easier, not harder, to write and read your programs. Some people think modern high-powered IDEs make the very idea of Hungarian Notation obsolete, but this is not the case. This notation not only shows the types of variables, it also shows relationships between variables. No IDE can do this better, assuming it can even figure out what those relationships are.
Here are some good reasons to use this notation:
- You’ll find it easier to think up useful names for things.
- You’ll find it easier to read code you wrote last week, or last year.
- You’ll find it easier to read code written by other team members.
- You’ll find it easier to read code written by code generators, and easier to write them, too.
- You’ll find it easier to script automated edits to your code.
- You’ll be able to write more aggressive code and get it right, especially if you’re using lots of pointers in C.
Here are some bad reasons not to use this notation:
- It takes a few days to get used to reading and writing this way.
- Some people foam at the mouth at the mere mention of Hungarian Notation.
So the obstacles are minor, and the payoff is great.
A Hungarian name has two parts: a prefix and a suffix. The prefix tells you what this thing is. The suffix tells you what this thing means.
The prefix is composed from a standard list of elements that a team agrees to use. In our dialect, prefix elements are always single lowercase letters, where each letter has a distinct meaning. There are no multi-letter prefix elements. Prefixes can contain several letters, however, because the elements concatenate. When prefix elements are combined this way, they always compound to the left.
The suffix may be null, that is, it may not exist, because in many cases a prefix alone is an adequate name, especially for local variables. If the suffix is non-null, it is composed from standard words written in CamelCase (the last word in this sentence is an example of CamelCase). Underscores are rarely used in a suffix. When more than one word is needed in a suffix, arrange them so the most important word comes first, with less important modifying words coming after, for example, ColorBlue and ColorRed. Don’t use abbreviations in the suffix except for those your team has agreed to use. Part of the reason for using this notation is so that everyone on a team will create the same names, even if they aren’t working closely together. Allowing indiscriminate abbreviations destroys this benefit.
When this is done correctly, program texts are found to contain families of names that “grow out from the middle.” They make it easy to see how the variables in your program are related to each other. This is one of the greatest benefits of this notation.
Two different Hungarian dialects are presented here: one for Java and one for C/C++. They are very similar. The C dialect was developed in 1990 and has survived years of hard use with little need for change during that time.