apps hungarian vs systems hungarian


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?Hungarian notation was all the rage when I started in IT, but it was a completely coding environment. A Simple text editor no syntax highlighting, intellisense and code files that where several hundred lines in length with all the variables declared at the beginning. It just made life easier in working out what you were dealing with. However with modern tools and practices the need for it has gone in my option and it really should be consigned to history.

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.I am also curious to see rationale. We know why they used it in the past: lack of IDE support for type information. But now? Simply put, I think it is a tradition. C++ code always looked like this, so why change things? Besides, when you build on top of previous code that used Hungarian notation, it would look quite strange when you suddenly stop using that.Apps Hungarian (tags to denote semantic properties of objects that can’t be expressed through the type system) was a reasonable way to deal with some common errors when using the weakly-typed languages of the early 1980s. They serve little purpose in today’s strongly-typed languages.

Systems Hungarian (tags to redundantly denote an object’s declared type) has never served any purpose except to impose a superficially uniform appearance on a code base. It was created and propagated by non-technical managers, and inexperienced programmers, who misunderstood the intent of Apps Hungarian, and believed that code quality could be enhanced by complex coding guidelines.

Both styles originated within Microsoft. These days, Microsoft’s naming conventions categorically say “Do not use Hungarian notation.”Hungarian notation has a bad rap. The initial prefix should be used to indicate the “kind” of variable, not the “type”.

Apps Hungarian had very useful, meaningful prefixes like “ix” to mean an index into an array, “c” to mean a count, “d” to mean the difference between two numbers (for example “dx” meant “width”), and so forth.

And functions would be called AFromB or something like that so that when you write it out it looks like:
aVar = AFromB(bVar);

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>