Hungary

When it coms to dynamic programming languages such as PHP and JavaScript, one of the things that people often debate is the use of hungarian notation.

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:

  1. You shouldn’t have to use Hungarian Notation – the context of your code should provide enough information.
  2. 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.

Practically speaking, it looks like this (in JavaScript):

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.

Clippy in Minecraft

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.

The Thing

On top of that, when you’re working with languages like JavaScript where everything is an object and has a set of methods that can be called on a variable, or you’re working with PHP where you may need to cast a variable to a different type (such as a string to an integer or vice versa), this helps in knowing that functions you can call on a variable.

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.

Category:
Articles

Join the conversation! 7 Comments

  1. Consistency should ALWAYS trump preference. If you’re coding for WordPress, use the WordPress coding standard. If you’re working on another project that uses Hungarian notation, stick with that. If you’re starting from scratch, do whatever you like. I find it irritating when a WordPress plugin has gone off in their own direction instead of sticking with WordPress’ coding standard. There’s little worse than looking at code written in a variety of styles.

    • Consistency should ALWAYS trump preference.

      Ah, yeah. I do agree with this.

      The thing is, I’m actually not sure what the conventions are – the current version of the standards don’t appear to show anything but examples of `$var`, for example.

      To that end, I usually just follow those that are outlined and then I end up trying to stick with consistency for the things that aren’t [yet] outlined.

  2. I have never been a fan of Hungarian Notation, mostly because a vast majority of my development experience has been in strongly typed languages.

    In strongly typed languages, I just found it to be duplicate work. Since a variable can only ever be what it was declared, there was / is no need to specify what it is in it’s name. It always will be what it is.

    Now, in weak typed languages, like JavaScript, I can somewhat buy into your argument. However, there have been a few hangups that have caused me not to adopt them in my development.

    Objects

    It’s easy to notate simple things like int, float, string, and boolean, but there is no easy or uniform way to notate objects.

    I am also not a fan of this when it comes to accessing variables within object. I really do not want to use Person.sName or Person.getSName(). Which brings me to…

    Readability

    There is something visually pleasing in the simplicity of Person.name. It reads well (which is part of the clean code principals) and removes any barriers in how beginner developers interpret the code.

    Full Featured IDEs

    Using a full featured IDE, such as PhpStorm or IntelliJ, versus a text editor will notify you of what variables are and in making common mistakes with wrong types, even if they are week.

    Unit Tests

    The necessity of notating variables is undone by using unit tests. They, by nature, guarantee everything proper and not squirrely.

    Conclusion

    Does that mean I will never use it? No. Standards and best practices always trump personal preference, so I will always go along with what is established within a project. But so far, even in the 2 years I’ve been using weak typed languages, I have not found a “need” to. In fact, I don’t find it to be a common practice at all in the code I’ve seen in a lot of open source projects from some very respected companies.

    • Yeah – when I was working with strongly typed languages, I didn’t worry about hungarian notation either because (a) the type was always defined with the variable and (b) the compiler would always yell if I was trying to perform an illegal operation.

      That’s not a luxury that we have with interpreted language, so I try to make the code as robust as I can prior to actually loading up in a browser (or command line or console or whatever).

      Anyway! To your points…

      • Objects. I’m with you on public interfaces. I’d never have `Person.getSName();`. Internally, the name would probably be declared as `sName`, but the public access to it would just be `Person.getName()`.
      • Readability. For this point, it looks like `Person.name` is a public attribute, which I dislike. I think that there should be getters and setters explicitly defined so that you can limit exactly what the developer can do with a given API. Other than that, I do like the readability of it if it were to be simplified to `Person.name();` and `Person.name(‘Tom’);`
      • IDEs. Yes – you’re right, but (and you know my stance on this) since not everyone uses the same IDE, I don’t bank on those features since I can’t assume that people are going to be using the same ones that I am using.
      • Unit Tests. There’s little to argue here – we’re in full agreement. The main problem with this is really when unit tests aren’t being used.

      At any rate, yeah – I think we generally agree. Standards will trump preference.

  3. I remember Hungarian Notation back from when I was dabbling in C++.

    But there’s a difference between C++ and PHP and JavaScript – in C++, you need to explicitly set a variable’s type before you can use it: `int bar;` or `char foo;`. Whereas in PHP and JS, a variable is dynamic, and its type can change depending on what value you assign to it. So you can make `$foo` and string like `$foo = ‘Hello World’;`, and then change it to an integer using `$foo = 42` .

    I never really liked the idea of using Hungarian Notation back in C++, but I did because that was the convention. I think that if you take care in naming your variables, then it should be obvious what value they contain. In my opinion, this notation just makes variable names look messy and unnecessarily long.

    • I’m with you: using Hungarian Notation in strongly typed languages in redundant, but I do think it really helps out in dynamically typed languages.

      However, as other commenters have noted, if the standards are against it, then I just suck it up and deal with it :).

  4. Great post. I will be fahing a few of these issues as well..

Leave a Reply