Hungarian Notation Postmortem: What Went Wrong?

Hungarian Notation Postmortem: What Went Wrong?

Note: I originally wrote this post for submain who have some great developer and DBA Tools.  
Submain is also where you can read the original post. 

Is Hungarian notation really adjDead? Suggesting a postmortem might be a bit premature, but it could be fun to take a quick dive into what we’ve learned from a really smart Hungarian named Charles Simonyi who tried to find a better way. Anyone who tries to bring some clarity to the chaos they find in their everyday dealings has a lot in common with us developers. Mr. Simonyi is one of us. Let’s hear him out!

What Is Hungarian Notation?

Hungarian notation is one of those topics of great debate in the programming community. You can find just as many intelligent and well-respected proponents as you can find opponents. Likewise, you can find lists about its positive contributions, and you can read articles on why it should never surface. As with most of these more philosophical debates, I find myself stuck in the middle. And when that happens, I find great value in hearing out those with strong opinions about it.

To a non-developer, computer code can appear rather ambiguous and obscure. To a developer, someone else’s computer code can be the same when we fail to be united in our approach. If you’ve spent any amount of time hacking away at a keyboard, writing complex computer instructions, I’m sure you’ll understand the concepts behind Hungarian notation. Mr. Simonyi is simply trying to bring some clarity to the language you’re using with your computer.

How Does It Work?

So, what is Hungarian notation and how does it work? To sum it up, Hungarian notation is a systematic approach to naming variables in our programs, using the type and a given name, in that order. If “lastName” is a string, think strLastname for its Hungarian notation. Consider this block of pseudocode:

string ln= “Simonyi”;
string fn= “Charles”;
string dn= ln + “,” + fn;
int len = dn.length();

It’s a pretty simple piece of code with a few string variables and an integer. Come on a quick journey with me; let’s say this was line 444 through 448 in 1000+ lines of code. The variable names tell us very little about what we’re storing in them. And when the variable is referenced further down in the code, we may find ourselves scrolling back up to find out what it means. If we used Hungarian notation, along with some better variable names, maybe we’d see something like this:

string sLastname = “Simonyi”;
string sFirstname = “Charles”;
string sDisplayname = sLastname + “,” + sFirstname;
int nLength= sDisplayname .length();

You’ll notice right away that the variable names are clear, their intents and purposes are solidified, and they’re prepended with the correct type (s for string, n for integer). No more guessing, and no more scrolling back to check the type.

That’s it.

Yup, that’s the basic idea behind Hungarian notation. And you can find article after article, opinion piece after opinion piece, and plenty debate all throughout the internets about it.

Why Did This Come About?

Let’s look at some quick history on Hungarian notation’s adoption and how it gained traction. Charles Simonyi was an originator of two programs we’re all familiar with, Microsoft’s Word and Excel. The Hungarian notation method of naming variables was part of his doctoral thesis before he introduced it, and it was adopted widely as a standard within Microsoft. This notation made its way into Windows programing and also Windows API programming. We know what a giant Microsoft is, and it’s there where this standard started to be seen—and questioned.

Of all the reasons Mr. Simonyi gives for creating Hungarian notation, the use case that stands out most to me is to provide further clarity for the “next guy up.” In my job as a developer in a large enterprise, I’ve been asked to debug and enhance programs in languages that are, well, just not very relevant these days. Large enterprise companies are warehouses for decades-old legacy code that no one wants to touch. Generally, if there’s a need to either enhance or rewrite that piece of code, guess who’s the next man up for the job? When you’re looking to debug a fixed asset depreciation process written in Dexterity 14 years back and you’re the “next guy,” this type of clarity can really help.

In general, it’s our responsibility as programmers to make our code readable. Submitting a pull request with generic variable names that mean nothing to our human readers is condemnable. Following standards and best practices makes our code readable, and Hungarian notation is just one of many standards and best practices.

So What Went Wrong?

Hungarian notation hasn’t gained full acceptance from the development community. Computer languages are different. That’s why there are more than one. These differences are vast and span across a wide range of how variables are used, types of variables, scope of variables, and the variables’ declarations.

In a strongly-typed language, like C or Java, our types are enforced by our declarations and then the compiler at compile time. It’s unlikely we can get away with any type mismatches, even in large chunks of code. Because of the strict compiler, the notation is adding redundancy and length to our code. Or from a more subjective approach, the notation confuses the readability of our code by adding strange type notation to our variable names, and that’s just not necessary.

But for loosely-typed languages, like JavaScript or Perl, putting type values in our variable names would definitely help, right? Unfortunately, the notation falls short again for similar reasons. While it helps us determine the type of the variable, does the type really even matter? We’re still adding redundancy and length, and we’re reducing readability in a condition where type checking isn’t even required. When we use loosely-typed languages, we’re using them for a reason!

A Better Way

Charles Simonyi was trying to bring clarity to an issue he dealt with in his craft. Hungarian notation shines a light on this issue that all developers face, and it’s led to great discussion on better guidelines for variable naming. These types of discussions/guidelines can be found all over the web: here, here, and more here.

Here are some of my favorites, not just because they help readability in my code but because they also help the “next guy up”:

  • Use variable names that communicate intent and purpose.
  • Use human-readable and pronounceable names.
  • Variables are nouns. Save the verbs for methods.
  • Use comments sparingly—explaining what your code is doing is precisely what code is!

The Takeaway

It can’t be too difficult to imagine writing code using Hungarian notation. Most of us developers think of our code as a work of art, so why would we litter it with repetitive type declarations and long variables? Writing good, clean code is a craft we developers take great pride in, and more importantly, our code tells the story of a problem we’re solving. When we standardize code style, our code loses identity and our craft becomes makeshift. While this is certainly not the intent of Hungarian notation or other standards and best practices, let’s use the best of what it suggests and move forward.

Next up, spaces or tabs…any takers?