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.
Tags: debugging, hungarian, Programming, style
The point that stuck with me most in Joel's post was the benefits of intelligent prefixing and suffixing that go along with Apps Hungarian. Joel's argument for apps Hungarian to me seemed strongest when he was making the following two (related) points:
1) Apps Hungarian is a method for intentionally making wrong code look wrong, something that descriptive names alone don't necessarily excel at.
2) Apps Hungarian places critical information about an object near the call to the object, rather than just at the object's definition.
In your post you touched on the first point, but then backed away from it to address the second point. Sure, descriptive naming can take care of putting valuable information about an object near the reference to it. This is because, as you mentioned, descriptive names are great in making your code self documenting. Self documenting code is good. However, it's possible for descriptive names to lull us into a false sense of security. This is where the first point comes in.
So, using the example of safe and unsafe strings, you could have an assignment somewhere in your program that looks like this:
web_ready_string = unsafe_string_to_web_ready(raw_input_string)
While contrived, it's pretty clear what's going on here from how the variables are named. In fact, it would be fairly simple to translate this into Apps Hungarian that would look something like this:
sString = usString_to_sString(usString)
If Apps Hungarian were done this way, I would agree with you. It's like descriptive names, but worse, because it's denser. However, I had an aha moment when Joel explained how you can make it easier to check your code if you change the order of the naming of your functions. So, what we have above becomes:
sString = sString_from_usString(usString)
Now it's easier at a glance to see that we're not only using the function correctly, but also naming our variable correctly. This is what convinced me that Apps Hungarian could be useful. To me it didn't really matter that we're using 's' and 'us', but more that Apps Hungarian can be applied to functions as well as other objects. Still, millage probably varies.
I see what you're saying, and it makes sense, and even looks like a great
idea. But then I remember what it was like when I worked with a team of
programmers who used Hungarian notation, while it wasn't Apps Hungarian, it
was still pretty awful.
I guess the main problem I have with Apps Hungarian naming is keeping track
of and remembering what the prefixes mean. It's just one more thing you need
to remember to do while writing your code, and distracts you from the real
task at hand, describing what you want to do to your computer.
I see what you're saying, and it makes sense, and even looks like a great idea. But then I remember what it was like when I worked with a team of programmers who used Hungarian notation, while it wasn't Apps Hungarian, it was still pretty awful.
I guess the main problem I have with Apps Hungarian naming is keeping track of and remembering what the prefixes mean. It's just one more thing you need to remember to do while writing your code, and distracts you from the real task at hand, describing what you want to do to your computer.