In What naming guidelines do you follow?, the author says:Also I prefer to code using hungarian notation from Charles Simonyi.I've run in to several programmers who still prefer to use Hungarian, mostly of the Petzold/Systems Hungarian flavor.  Think dwLength = strlen(lpszName). I've read Making Wrong Code Look Wrong, and I understand the rationale for Apps Hungarian, where domain-type information is included in the variable names.  But I don't understand the value in attatching the compiler type to the name.     Why do programmers still persist on using this style of notation?  Is it just inertia?  Are there any benefits that outweigh the decreased readability?  Do people just learn to ignore the decorators when reading the code, and if so, how do they continue to add value?EDIT:A lot of answers are explaining the history, or why it is no longer relevant, both of which are covered in the article I cited. I'd really like to hear from anyone out there who still uses it.  Why do you use it?  Is it in your standard?  Would you use it if it wasn't required?  Would you use it on a new project?  What do you see as the advantages?
What is the appeal of Systems Hungarian?
coding standards;hungarian;notation
At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:To be consistent with an existing code base when doing maintenance.For controls, eg. txtFirstName. We often need to distinguish between (say) firstName the value and firstName the control. Hungarian provides a convenient way to do this. Of course, I could type firstNameTextBox, but txtFirstName is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.When two variables hold the same value but differ by type. For example, strValue for the value actually typed by the user and intValue for the same value once it has been parsed as in integer.I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.Update:I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.