Apps Hungarian is Just Good Naming

Last updated on 06 Feb 2009

Application Hungarian is just good variable naming convention, but worse, because it’s needlessly concise, and hard to read at a glance. It also comes from an environment that is growing more and more obsolete. More on that in a bit.

Firstly, clarification is needed as to the definition of Application Hungarian notation, as opposed to Systems Hungarian. All of this is relatively useless, however, if you are in the same situation I was in a few years back and don’t know what Hungarian notation even is.

Hungarian notation is a variable and function naming convention where you add either prefixes or suffixes to names. What these prefixes/suffixes mean depends on what type of Hungarian notation you’re using. Systems Hungarian is the method of adding information about the type of the value of a variable, or a return from a function. For example, a string that represents a name would be called “strName” using Systems Hungarian. Applications Hungarian is where you add information about the semantic meaning of the value of a variable.If this is a little foreign, that’s because most people think Systems Hungarian when they think about Hungarian notation.

In Making Wrong Code Look Wrong, which is what inspired this post, Joel Spoelsky outlined exactly what Applications Hungarian notation is, and why it’s so useful. He outlines that in Applications Hungarian, you add information about the semantic value of a variable/method return. To illustrate, he demonstrates that you can use Applications Hungarian to differentiate safe and unsafe strings in a web application environment. He uses the prefix ‘s’ to define a “safe” string, that is safe against XSS attacks (ie: A html encoded string). He uses the ‘us’ prefix to define an “unsafe” string, that is a string read directly from user input that may contain potentially dangerous code.

Spolsky also demonstrates using the notation to make wrong code long wrong. That is, by combining prefixes on methods, based on their return types, you can use the names as a sort of litmus test. So if the return prefix of a function specifies it returns a ‘us’ or unsafe string, and you assign it to a ‘s’ or supposedly safe function, this is clearly a logic bug, and looks wrong.

I think this is great, and it’s something I’ve never thought of, but my question is, how is it different from properly descriptive variable naming, aside from it’s somewhat obscure brevity?

The virtues of clear, descriptive names in programming have been sung again and again. If you make your variables and method names descriptive enough, your code becomes somewhat self documenting. You capture the intention and meaning in your code when you use variables like “customerFirstName” and “formatAddress”. You look at those names and you can immediately see the intention behind the code.

I see a huge overlap between the best practice of descriptive variable naming and Spolsky’s intention behind his use of Apps Hungarian, so much so that I don’t see a difference between the two, with relation to their purported goals. Apps Hungarian is more terse, and more obscure, and has somewhat of a learning curve if you’re not familiar with the nomenclature of the system. This, to me, seems like a needless barrier to understanding.

Am I missing something? Why is Apps Hungarian better than regular, descriptive and intelligent variable naming? I can’t see any benefit to using Apps Hungarian explicitly, and to my understanding, Apps Hungarian is just a more terse method of good variable naming.