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.
June 24th, 2009 | 6 Comments
June 27th, 2009 at 10:41 am
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.
June 27th, 2009 at 2:05 pm
@Kevin is right. You can have
labelName
editName
where the prefixes become important.
June 27th, 2009 at 9:16 pm
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.
June 27th, 2009 at 11:40 pm
And let’s not forget what happens when the type of a variable name specified with Hungarian notation changes.
June 28th, 2009 at 10:50 pm
@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.
July 6th, 2009 at 8:14 pm
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.