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?
Learn how GhostDoc can help to simplify your XML Comments, produce and maintain quality help documentation.
27 Comments. Leave new
Also very important in complex programming is to make visible the difference between source data and derived data, so it is clear to the programmer when he is doing interpretation of derived data – keeping in mind that it is better to do interpretation on the source data (not on derived data) if possible. For instance, prefix variable names with underscore if the variable holds derived data.
I’m curious — in what framework/stack is this idiomatic, in your experience. For instance, I’ve seen a lot of C#, Java, and even C++ over the years, where the prepending underscore denotes a class field.
I don’t think it’s valid to say Hungarian Notation “Went Wrong”. it solved the problem it was meant to solve and now we have better solutions. The big reason Hungarian Notation is no longer used is that IDEs have advanced to the point that it’s not necessary. I can hover my mouse over a variable and the IDE will tell me it’s type so it’s unnecessary to also include that information in the variable name.
If you are using older IDEs then Hungarian Notation may still be useful. Our mobile application runs on WinCE and requires us to use Visual Studio 2008. Visual studio 2008 has a bad habit of going “I have no idea what this variable is, I don’t even think it is a variable, what the hell is this?” so having the type information as part of the name is useful. So we still use Hungarian Notation in that project but not in other projects that work on newer IDEs.
I think that the Hungarian notation suggested for pointers (prefixing with ‘p’ for a simple pointer, pp for a pointer-to-pointer) is still quite useful – especially for programmers just learning to use pointers. The notation hints directly -and succinctly- about the available indirection levels on a variable, and IMHO helps to build a mental pattern that simplifies writing pointer-centric code.
“Use comments sparingly”.. Big mistake IMHO. Comments do not explain what your code does (as you say, the code does that). They actually explain what your code is intended to do (and as such are an aid to correctness and also debugging) and should therefore be liberal, not sparse. If your comments say the code is intended to do ‘x’ and it is clear on examination that it does ‘y’ you know there is an error (in one of them at least). If the code says it does ‘y’ and there is nothing to say it should be doing something else, you just don’t know.
Yes, it is important to explain what the code is supposed to do. Even more important though is explaining the context in which the code is expected to run. What are the assumptions about the environment? What needs to be initialized first? Does order of initialization or execution matter? These kinds of things are clearly in the mind of the programmer writing the code but would not be at all obvious to the “next guy up.”
I learned Hungarian notation back in the early ’90s writing C and then C++. Given the primitive tools of the time Hungarian notation really did make code easier to read. Now, like the author says, use descriptive nouns with casing or underscores to aid readability.
I’m rather disappointed that the article makes no attempt to distinguish Systems Hungarian from Apps Hungarian. The difference is substantial. In Apps Hungarian, it’s not the data type that’s used for the prefix(es), but the semantic kind, so “row” and “column” indexes get different prefixes in Excel (despite both being the same size of integer), strings from user input get a different prefix from strings that have been sanitized, and so on and so forth.
Systems Hungarian is the mixed-up, basically useless misunderstanding of Hungarian notation popularized in the Win32 API that most people (including, obviously, this article) think of when they talk about it. Because no, knowing that displayName is a string isn’t particularly interesting, especially with decent IDE support for strong static typing. But knowing that displayName comes from unsanitized data? That’s a whole different story, and anyone who still struggles with injection attacks would benefit.
Yes exactly. Hungarian was designed to distinguish things that are stored in the same type but otherwise unrelated. hHandle = cbStrlen should set off a warning because it is 99.99% unlikely you want to assign a count of bytes (indicated by cb) to a handle (h). The article completely misses the point.
Marking your variables in such a manner would certainly help keep things correct. But you could also wrap the string with two new classes. One for sanitized and one for unsanitized. Then you could make it impossible to treat the unsanitized as sanitized later in the development cycle. Or, you could ensure all data gets sanitized very early in the process cycle.
I totally agree. I remember an Article by Joel Spolsky where he explained how to reduce semantic errors in web code dealing with encrypted and unencrypted strings: he used different prefixes for both, and function names that indicated which strings they would work with by incorporating the corresponding prefixes.
Another example is using prefixes to indicate degrees or radians, millimeters or inches, in programs that are required to work with either of these measurements. When you do arithmetics with such values, which is more prone to errors: writing
double dAngle = dAlpha +dBeta;
or
double radAngle = degAlpha + radBeta;
?
If the answer isn’t apparent to you, you haven’t understood the purpose of (Apps) Hungarian.
By the way, found the article I mentioned above:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
Thanks Stefan that?s a great write-up about why Hungarian is powerful when used properly – Quote “Somebody, somewhere, read Simonyi?s paper, where he used the word ?type,? and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word ?type,? but it didn?t help. The damage was done. ”
Joel Spolsky – great article – https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
A few years ago, I had a link to the definition and explanation of Hungarian naming notation; I lost the link at some time while getting another new PC. Hungarian naming notation was not invented by Microsoft, I think I was programming on a PDP-11 when I first started reading articles about naming conventions for variables, this was a few years before windows 2.1 was released on a 5 1/4 floppy disk.
Short rant: I’m also not a fan of Microsoft; the number of black and blue screens of death that have destroyed my workflow is enormous. The concepts of Hungarian naming notation go way back before Borland created visual studio and way before word perfect created the first decent macro programmable word processor using word plussy – before VBA and visual basic were created.
Do you even code, bro?
Interesting – I think I agree with every previous comment, I would add: – Creating a list of comments before you start coding is a useful strategy for rookies and hackers; it splits your design thinking from your code thinking, and helps to ensure you don?t forget to address a technical issue. Comments are useful for folks creating white box tests, who might be creating CI test algorithms, at a different location to the person who created the original code. I can?t stress enough, how useful comments are, when you need to add a feature to your own code several months later. Reading comments is faster than reading code since they act as a simple aid, to helping you home in on a specific code block, that needs to be modified, when adding a business feature. Neil Haughton makes one of the most important points about code commenting, and how comments help folks who have to fix a software malfunction. Working through several thousand lines of code, comments add clarity and suggest useful places to insert a breakpoint. For folks who are doing a design review, comments are polite.
Does code self-describe, self-explain, does it speak ? yes ? when it?s crafted, when the coding problem is simple and pleasing ? when the code architecture is not complex. On the other hand, if you are coding a state machine that uses FIFO buffers that act as command queues ? you better have good comments and some good visio drawings to elaborate the state sequencing, otherwise you will get lost.
One thing that?s worth mentioning is one of the main reasons why Hungarian notation came into existence and caught on in a big way. Some Folks used to deliberately create cryptic code, as a way of safe guarding / protecting their jobs. When Hungarian naming notation came out, it gave permission to hit back and complain and to challenge folks who were deliberately creating cryptic code.
Hungarian notation started to be used less when computers went past 16bit data busses and integers and word data types morphed into small, medium and large /double integers; at this point the Hungarian naming started to go beyond using 2, 3, 4 character preambles to describe the data type containers. Like all good things, it has its limits; within the right context however (Nathan Tuggy mentions VBA / I could add TSQL, ?) Hungarian naming still has value.
That’s an interesting tidbit about pushing back against the “job security through obscurity” types of developers. That effect wouldn’t have occurred to me. I’m always amazed at people that (to this day) do things like that, given what a shortsighted career strategy that is.
Hi Erik, I don?t think there is such a thing as job security, but there is / should be an understanding that code is a living thing in the same way that a business is a growing thing. Computer software and design grows in line with the aspirations of sales, needs of customers, advances of what new technology offers, business refactoring / pivoting needs to reorganise, legal / legislation / standards drivers.
In order to maintain competitiveness, cash flow and customer interest, software maintenance and adapting the CI supported code base, is a large part of what facilitates business growth.
Hungarian notation has deep roots in FORTRAN and BASIC. In FORTRAN, variables i, j, k, l, m, and n were integers, while other variables were floating point. In BASIC, numeric variables were a letter (later a letter followed by a letter or number) like a, b, or x, while string variables were a letter followed by a dollar sign, like s$, a1$, etc. So the idea that a variable’s name also told its type has a long history.
The other root of Hungarian notation came from memory models. You young whipper-snappers don’t remember this, but in the bad old days there was more than one kind of pointer. Short pointers could only point to data within a single 64-Kbyte page, or sometimes a 640-Kbyte page with page register, while long pointers could point to any data. Short pointers generated more efficient code than long pointers, which made a big difference because the program text itself was sometimes limited to 64-Kbytes. A command line switch to the compiler told you what the memory model was. There were like 12 memory models, each with different combinations of long and short pointers, maximum program size, etc. There’s an article on Wikipedia that is a grim reminder of all this pain. Eventually processor-makers heard the collective screaming of software developers and built a uniform 32-bit memory model, then a uniform 64-bit memory model, and there was once again just one kind of pointer.
This gave you variable names in Hungarian that looked like lpszName, which meant a long pointer to a string that was zero-terminated, and called Name. Arguments to Windows functions had to be long pointers, and you’ll still see lp prefixes to many argument names.
I definitely remember names like lpszName (or, worse, something like lpszNm if people abbreviated the non-encoded portion) from days long gone with Visual C++, pre .NET days. Can’t say I go as far back as FORTRAN in its heyday, though. That’s interesting background about the memory models — thanks for mentioning it.
“Use comments sparingly?explaining what your code is doing is precisely what code is!”
That’s another great debate in the programming community. Having dealt with a LOT of entry level coders coming in to maintain code, I favor robust comments. Sparse comments are fine when you are dealing with a group of experts who know the language, app, and business rules well, but it’s a nightmare when you just don’t know who is looking at your code next. It takes seconds, just do it. (again, unless you know only seasoned vets that know their way around the project are coming in after you)
“Use comments sparingly?explaining what your code is doing is precisely what code is!”
This is fine for when your code is immediately obvious to the most casual observer, but once you get on edge cases for optimization and fluid dynamics, it becomes quickly apparent that you should explain some of what you are doing more in depth. So for all of you developers stuck in the world of calculating the number of pixels across your window is, please go ahead and just use your code to explain it. For those attempting to create sophisticated mathematical simulations, please describe what you are doing and when possible give source references. Everyone, including you, will appreciate the help 10+ years later.
As for the rest, I used Hungarian notation in the 90s and early 00s, but as you point out, there are other ways to be explicit of your intent.
The central argument in favour of Hungarian dis-ingeniously merges two separate ideas: “If we used Hungarian notation, along with some better variable names”. Better variable names are what make the resulting code fragment better, not the Hungarian notation.
Hungarian had value in its day, with C (I would dispute the claim that it’s strongly typed) and weak IDEs or even simple text editors. Embedding the type information within the variable name would indeed have saved time and aided understanding.
Nowadays, with strongly typed languages and much more powerful IDEs, the same information is available with a swipe of a mouse without entrenching the data design within the names of every variable.
I’m not sure I would say anything went wrong – more just that it solved a problem at the time, and that problem went away.
John
I agree that Hungarian has had its time for some development tools; it?s a little early to be calling last orders when script based and type less languages are in common use
BUT
Swiping variable after variable after variable is helpful with understanding the program flow ? really? In eclipse or android /visual /Atmel studio and many other tools; its distracting having to swipe each and every thingy on the screen, just to understand if that thing is passive / active – a class object containing nested functions / features / pointers / event hooks / etc. or it?s just a straight variable.
Crafted code needs to speak and explain itself, without, in itself, becoming a distraction. ? no GUI is going to recover FUD code
wiz bang hover mouse time delay popups – can – get in the way of interpreting what?s going on.
Having to swipe multiple things – and wait for a 2 second time delay popup window to announce it?s a bla bla class (which in itself require another mouse hover swipe), just to understand what?s going on – then that GUI is visual Babbage
[…] authors!? Carlos had a post on NDepend?that went viral, netting over 10,000 views, and Rick had a post on SubMain that did about 5K.? Not bad for a couple of first time client […]
[…] 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. […]
There are many flavors of Hungarian, and two broad categories – apps and system. The type-name approach is only one. Hungarian gets used all the time in the suffix form – homeController, personReader, etc, are all forms of Hungarian. Instead of prefixing with a primitive type, this version uses a suffix of a complex (e.g. Class) type. But it is still technically Hungarian.
thisIsAGoodPost.
Indeed precisely. Hungarian was intended to recognize things that are put away in a similar sort however in any case irrelevant. hHandle = cbStrlen should set off a notice since it is 99.99% far-fetched you need to dole out a check of bytes (demonstrated by cb) to a handle (h). The article totally overlooks the main issue.