The Cons and Cons of the Hungarian Notation
wMaybe wthe wheadline wof wthis warticle wgave wyou wa whint wabout wmy wposition won wthe wHungarian wnotation p.
And maybe the above sentence does, too.
Hungarian notation can mean several things in programming, but the common meaning is that it’s a convention to prefix the name of each object in code with a tag about its type.
To illustrate what’s wrong about the Hungarian notation, consider the opening sentence of this article. It sort of follows the Hungarian notation. Indeed, it has several elements, most of them words, and they’re prefixed with the letter ‘w’ to indicate it. And it finishes with a period, which is a punctuation, hence the p before it.
Find it useful?
A spillover of lower levels of abstraction
Okay, that example might be pushing it a little, but that’s the gist of it: Hungarian notation pollutes code with information that you don’t care about.
But why is this information not so useful? It’s about types. Aren’t types important?
Object types are very useful when designing and writing code. For example, you can only pass certain types to certain functions. But when you read code, apart in some special cases (e.g. strong types, that have higher levels of abstraction), I think you don’t care as much about types.
Indeed, if you’re reading code that compiles (which is virtually always the case when reading code), you know that the right types have been passed to the right functions, because otherwise the code wouldn’t compile.
What you care about is the role of objects, rather than their types. Types are lower in terms of level of abstractions: types are how objects are implemented. What you want to know when reading code is rather what they represent, which means their role. And the role of an object is already encoded in its name.
So the information brought by Hungarian notation is not so useful to read code. And code is read much, much more often that written. But let’s suppose that you’re writing a piece of code that you know won’t be read a lot. Is Hungarian notation helpful then?
In practice, when writing code, we should have a pretty clear vision of which object that we are creating is of which type. If we can’t follow along the code we’re writing, and need a visual help to help remember the types our objects, then there is another problem.
Indeed, the moment we’re the clearest about a piece of code is when we write it, because we have all the context in our head. We’re “in the zone”. If we can’t follow along when writing our own code, imagine how hard it will be for somebody else reading it, at a later point.
Moreover, there is not that much info in the Hungarian notation anyway. Indeed, the prefix for all objects that are not of primitive types (so not int, double, char* and so on) is x. An Employee has x, just like a strong type for a serial number would have x. Not so rich information.
But my codebase is all Hungarian notation!
This is one of the main arguments for maintaining the habit of Hungarian notion when writing code in an existing codebase.
Indeed, the Hungarian notation is something from some time ago (back then, some languages that didn’t have types at all, such as BCPL, made the Hungarian notation look attractive, even if for dubious reasons), so some codebases started out with it, and grew in size over the years.
But this is not where programming is going. Since C++11, in a lot of cases we no longer even see the types in type names themselves, with the advent of auto. And this is not just C++: Java also has an equivalent feature since Java 10: var.
Now if your codebase follows the Hungarian notation, is it OK to introduce objects that don’t? Wouldn’t it break consistency?
Consistency is a valuable thing, but there is a point where being overly consistent means that we can’t improve, because we can’t change anything. This is the point that Jon Kalb is making in his famous Foolish Consistency article.
And, in the particular case of Hungarian notation, I find it’s really OK to break consistency. I have faced the very case, and initially thought that I should break free from the Hungarian notation only in brand new code.
But it turns out that it doesn’t make the code confusing at all, if in same region of code some objects don’t follow the Hungarian notation and some do. The former are just easier to read than the latter. It may be my personal opinion, but I was surprised by how little of a problem it was.
Never add anything to a name?
Does this mean that we should never ever prefix anything to a name? Not necessarily.
I think that the info in prefixes shares some similarities with comments. Indeed, both are additional info in the source code, meant to give some indications to a reader.
And when it comes to whether or not to write comments in code, my main guideline is this:
Imagine what you would need to tell someone who is reading your code, if you were sitting next to them. That is what you put in comments.
You could adapt this guideline by replacing “comments” with “prefixes”.
Imagine what you would need to tell someone who is reading your code, if you were sitting next to them. That is what you put in prefixes.
In this analogy, reading Hungarian notation would be like having somebody sitting next to you, telling you for each object: “Hey this an integer!”, “and this is a pointer!”, “and this is a user-defined type!”, “and this is also a user-defined type!”, “and this too!”, ranging from useless to annoying.
But there is valuable info about code that its author could tell you if they were sitting next to you. And why not put it in a prefix, if you should be reminded about this info each time you encounter that object.
It seems that this is what the Hungarian notation was designed for in the first place, but it got badly misinterpreted over time. For more examples on this, check out Joel Spolsky’s website, where he defends certain prefixes that follow the initial intention of the Hungarian notation.
But when it comes to the meaning of Hungarian notation as most people use it, my take is that we should drop it, focus on good naming for the rest of the name instead, and move along with the future of programming.
You may also like
- The original paper on the Hungarian notation
- How to choose good names in your code
- To comment or not to comment? // that is the question
Share this post!
