Like most things with programmers, the debate can easily become something that resembles a religious argument. The debate normally hits on the following two points:
- You shouldn’t have to use Hungarian Notation – the context of your code should provide enough information.
- You should use Hungarian Notation – it helps with readability of the code.
For whatever it’s worth, I prefer to use Hungarian Notation. And though I’m not exactly one who elevates things to a heated debate, I’ve found as much as I’d like context to provide me with enough information, I don’t always see this as being the case in projects.
What is Hungarian Notation?
Straight from Wikipedia:
Hungarian notation was designed to be language-independent, and found its first major use with the BCPL programming language. Because BCPL has no data types other than the machine word, nothing in the language itself helps a programmer remember variables’ types. Hungarian notation aims to remedy this by providing the programmer with explicit knowledge of each variable’s data type.
var iMyNumber = 42; var sMyName = 'Tom'; var fMoney = 10.20; var bIsOn = false;
In short, a single character is prefixed to a variable to denote its data type. The problem with this is that it’s often been abused within object-oriented programming – developers will actually prefix the object’s name to the variable.
This is basically an abuse of the notation, but I digress – especially when this particular Stack Exchange question does a better job of covering it.
“The Context Doesn’t Help.”
As I mentioned earlier, though the context of a variable should provide enough information as to what type of data a variable references, it can often get lost over time when functions are modified.
Ideally, a function should remain relatively small – Bob Martin claims they should be 20 lines or so – which would include variable declarations. This would be good because we’d be able to see all of the information on the screen of the IDE and refer back to what type a variable it is with which we’re working.
The problem is that keeping functions around 20 lines is tough, and rarely done. I’m guilty of this, for sure. As such, it’s easy to lose track of what type of variable you’re working with.
On top of that, if you’ve ever worked on a team of developers, it can become increasingly challenging to introduce new code into a program in order to add a feature or fix a bug without making an existing function longer – over time, this makes functions longer, more convoluted, and ultimately have them doing more than they originally intended.
Though I really do like the idea of striving for shorter functions, no identifiers on variables, and general ease of maintenance, I’ve yet to see this done well in larger projects both in the enterprise and even some of my own work (which is probably content for a post in and of itself).
“What is This Thing?”
To that end – and perhaps I’m simply pessimistic in that I expect things to eventually break down – I prefer to use hungarian notation if for no other reason than it serves as a reminder as to what type of variable is being used.
For example, if I’m working with a string and I’m going to be manipulating it within the context of another function, then knowing what methods are available to me helps in writing code to work with it.
On the other hand, I may be waiting for the parser to provide an error message in the console, in a white screen, or in whatever runtime environment exists.
Finally, and perhaps the most simplistic reason, I think that hungarian notion makes the code more readable which contributes to ease of maintenance and helps others add to a project whether or not it’s open source by knowing what’s what when working with the codebase.
Does This Really Matter?
When it comes to talking about stuff like this, part of me even wonders if this is worth debating, or if it doesn’t become a wash by the time everyone is done sharing their opinion.
Ultimately, I think that decisions on things like this are right in line with coding standards and are up to the decisions of the team working on the code. There won’t be some sort of universal standard – just opinions that people have on how it should be written.
And, really, the only place we have control over that is within our own projects or on our team’s projects.