I was just scanning StackOverflow looking for interesting Questions and Answers, and happened up this one: Converting JSON to C# Class Object. Serialization is always an interesting subject, and I had previously thought about the idea of serializing (or deserializing) to and from JSON, so I had a look. The questioner was having a problem getting JSON serialization to work, and asked if anyone could see what he was doing wrong. Well, I certainly couldn’t see anything (since I’ve never dealt much with JSON — that’s “JavaScript Object Notation” for those of you wondering about it — it was Greek to me).

But what caught my eye the most was a comment to the question. See, the questioner’s displayed code contained data names like this one: “strMapPolicyID”. Note the “str” prefix. This is one way to indicate that the object in question contains a string. Or “intZoomLevel”, where “int” indicates that it contains an integer. This kind of notation is what is called “Hungarian Notation”, and in some (most?) programmer’s minds it is a thing to be avoided like the plague. The comment in this case was:

Don’t use Hungarian notation. It’s bad practice generally, and totally unexpected when working with JSON. – Panagiotis Kanavos

This annoyed me. There’s nothing wrong with Hungarian notation, per se, any more than there’s anything wrong with Hungarian. In it’s proper place (amongst Hungarians), the Hungarian language is perfectly appropriate. And Hungarian notation has its place, as well. I don’t use the style of Hungarian Notation expressed in the StackOverflow question (I used to, long time ago), but the inventor of the notation, at-that-time Microsofty Charles Simonyi (who is, by the way, Hungarian), didn’t encourage this version of the notation that most programmers are familiar with anyway. This idea of prefacing each variable name with a short indicator of the object’s underlying data type (such as “str” or “int”) is a tautology, and was not what Simonyi had in mind.

One should read Simonyi’s original article on the subect, on Microsoft’s Developer Network site: http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx

The kind of prefix that Simonyi argued for was the functional prefix, not the data type. For example, if an integer was intended to represent a color, specifically the color red, the variable might be named coRed. Or, if it was supposed to represent the color of a house, coHouse. I don’t have time to provide a precis of Simonyi’s article — just read it.

The simple fact about Hungarian notation is this: what most programmers think is Hungarian notion isn’t. They’re abusing a straw man.

I still use Hungarian notation for names of controls in web pages and windows forms. For example, I might name a textbox txtFirstName, or txtAddress1. What this does is enable me make sure I am addressing all related objects. On the other hand, if I had a lot of textboxes, I might group them in nominal groups, such as a set of textboxes intended to collect or display address information. For example: addrStreet1, addrStreet2, addrCity, addrState, and addrZip. The fact that addrState might be a dropdown containing all 50 states is not important, but it IS important that it enables me to more easily code to them all because auto-completion (Intellisense in Visual Studio) would help me make sure I got them all during coding to access them. And that is the proper role of Hungarian notation — not to mention the proper definition of Hungarian notation.

By the way, there are a couple of blog posts from famous programmers on the subject that bear linking to:

• Jeff Attwood’s Coding Horror on “Hungarian Wars“
• Joel Spolsky’s Joel on Software blog on Making Wrong Code Look Wrong

And, as always, have fun coding!