Hungarian notation, what do I think?

A girl at work asked me yesterday about whether or not encoding a variable’s type into its name — aka Hungarian Notation — was a good idea (she’s a designer who secretly wants to be a developer). I thought I might have written an article here before about it, but it seems I haven’t, so here goes.

Encoding the purpose of a variable into its name is a good idea. For example:

customerForm
passwordHash
firstName
submitButton
bodyHtml
errorMessage
countries (plural = a collection of some sort)

This is just common-sense good naming.

On the other hand, I think encoding the variable’s runtime type into its name is brain-damaged — it usually doesn’t help much and just decreases code clarity. For example:

strName
strMessage
iAge
arrNames
dsEmployees

I don’t think prefixes like this add any real value at all, because you could probably guess what type they are from their names and context in which they appear. Therefore they are simply clutter.

If you need them, however, then that suggests to me you have either 1) poor variable names that fail to properly explain their purpose or 2) your methods are too long and need to be refactored. Either way, fudging variable names so you can remember what type they were declared as 300 lines earlier is not the right answer, and will probably make your code even less readable.

The difference between these two naming styles is officially known as apps vs systems Hungarian notation. Joel Spolsky has a good article on the difference and how one became perverted into the other here.

6 thoughts on “Hungarian notation, what do I think?

  1. The area I find Hungarian handy is when the variable refers to a GUI control: combobox, button, text area, etc. A bit harder to make the variable name indicate what it is in those cases.

  2. I’d agree with Kevin and Johniy. Prefixes are very useful when referring to GUI elements. It allows do a find within a document of any references to GUI elements very quickly and effectively seperates those variables from those used internally to your methods etc.

  3. And let’s not forget what happens when the type of a variable name specified with Hungarian notation changes.

  4. @Kevin: agreed. I too have used hungarian notation for UI controls in the code behind ASP.NET pages, where in a single context you often have variables of different types that all share the same name — eg. txtFirstName for the textbox UI control + firstName for a string with its value.

    In these situations however, I think it’s only done because you can’t have multiple variables with the same name, and you need to know which one is the control and which is the value inside. The actual type of control is of little importance: uiUsername would be just as useful as txtUsername I think.

  5. Even for GUI controls, I’d probably not include the control type in the variable name. Say you’re accessing the “address” control, it doesn’t matter if that control is a simple textfield or a compound component with a seperate field for street, city,…

    You should try to orangize your code in a way that you can do “addressField.setValue(person.getAddress())” without worrying how the field will actually process/display that data. This way you can reuse your components without actually having to think about they work internally on every usage.

Comments are closed.