A famous quote in programming circles goes as follows:
There are only two hard things in Computer Science: cache invalidation and naming things.
Hungarian Notation is a system that attempts to make naming things a little easier. You may come across Hungarian Notation when exploring an existing codebase. You might have a colleague who is particularly keen on using it. But what is it, and what does it look like? And should you really be using it?
What Is Hungarian Notation?
Hungarian Notation is a convention on identifier naming. It’s mainly applied to variable naming, but it can also cover the naming of functions. The notation is an attempt to formalize how a variable’s name can indicate its type or purpose.
Using Hungarian Notation, variable names all begin with a group of letters with an agreed meaning. These letters are typically an abbreviation for the type of variable. For example, the letter l might represent a long integer. The abbreviation str represents a string.
Is It Really Hungarian?
Yes, Hungarian Notation was, indeed, invented by a Hungarian! Charles Simonyi was a Microsoft employee when he invented the term. He was a programmer at the company, working on application software.
In contrast with most other Western languages, Hungarian names order the family name first, followed by the given name. The term Hungarian Notation may reference this fact, or it may just be a happy coincidence. It could just have been more natural to Simonyi because of his native language.
What Does It Look Like?
Rather than naming a variable simply age, Hungarian Notation includes a prefix representing that variable’s type. For example, in C, a programmer might declare such a variable as follows:
int iAge;Note that, because C is a strongly-typed language, the i prefix is redundant at the point of declaration. However, when using the variable later on, the prefix proves useful:
printf("I am %d years old", iAge);The prefix helps to remind us that we’re using the correct type of variable.
In a weakly-typed language, such as PHP, variables can adopt different types according to the value they hold. So Hungarian Notation is potentially more useful:
$iAge = 21;Here are some more examples of a common Hungarian Notation scheme:
| Prefix | Type | Example |
|---|---|---|
| b | boolean | bLightsEnabled |
| c | character | cLetterGrade |
| str | string | strCategory |
| i | integer | iWheels |
| f | float | fMiles |
| C | class | CPerson |
| {class name} | object | personLeader |
Systems Hungarian Versus Apps Hungarian
Hungarian Notation has a split. In one corner, we have Systems Hungarian, in the other, Apps Hungarian. The difference is subtle but all-important.
Systems Hungarian is the version that people often associate with Hungarian Notation. It deals strictly with the type of the variable, as we’ve shown above.
Apps Hungarian attempts to encode the purpose of a variable rather than its data type. This is a much broader concept, so examples can cover many different use cases:
// an Unsafe String e.g. a name the user entered in a web form
$usName
// the Length of the vertical side
$lVertical
// a Count of references to an object
$cRefsApps Hungarian was the original form of Hungarian Notation, and describing purpose was Simonyi’s intent. Systems Hungarian is something of a mutation, one which many argue is for the worse.
What’s Good About Hungarian Notation?
As we mentioned earlier, Systems Hungarian can be useful for weakly-typed languages. It allows someone looking at code to instantly determine the type of a variable, whenever it appears.
Hungarian Notation also helps to enforce consistent variable naming. After all, bad variable naming is one of the most common programming mistakes. Apps Notation might help programmers spot important errors that the language wouldn’t otherwise alert them to.
And What’s Bad About Hungarian Notation?
In general, Hungarian Notation has fallen out of fashion. In strongly-typed languages, it’s broadly redundant, especially the Systems Hungarian type. It can also make code more difficult to read. Any problems it might help solve are often signs of deeper flaws, such as an over-reliance on global variables.
Apps Notation looks to have more going for it, but even this version has its detractors. There’s a good argument that information about purpose should still be part of the variable’s type.
Any language that supports user-defined types or classes can usually achieve the same aims in better ways. Naming a variable usName won’t make it any safer. But creating a class named UnsafeString allows a compiler to check a variable’s type.
Should I Use Hungarian Notation?
Ultimately, that choice is up to you. If you’re working in a larger team, someone will probably make the decision and everyone should go along with it. If you’re writing your own code, you can decide based on the arguments above.
But you might want to heed the latest advice from Microsoft, the company where Hungarian Notation originated. Since 2008, their General Naming Conventions have included this simple note:
❌ DO NOT use Hungarian notation.
