Title: More Thoughts About Hungarian Notation

The Harpist's reply to my article on Hungarian notation (C Vu 11.1) draws out more explicitly the concepts I was groping towards. We need to distinguish between two aspects of Hungarian - "type-specific" and "scope-specific" identification. Hungarian is invaluable for the latter but not for the former.

The Harpist does make some concession towards type-specific identification, e.g., for pointers. The suggestion that we use suffixes rather than prefixes is probably a good one and it does follow the C convention for typedefs. Nevertheless, my personal preference is to use prefixes, probably because this style is more widely used and so I am used to it. Most of the time, in a commercial environment, one's code must integrate with that of others and, if Hungarian is being used, it is usually the prefix form. It would decrease readability if I were to adopt the suffix form in such instances.

In my earlier article I mentioned that adopting Hungarian for UI widgets was very useful. Although this is type-specific identification it is not as disruptive as type-specific identification for simple data types. This is because, with the former, a change of choice of UI widget usually necessitates a change in the program structure as well. So going through the code and changing "txtBox" to "cmbBox" is not simply a tedious exercise but also necessitates a code rewrite, as the methods for the two object types are different.

But for simple data types the only thing we have to do is change the identifiers, as their "methods" are just operators and these are more-or-less common between data types. Such an exercise then just seems like an unproductive chore, despite the fact that modern code editors make it easy to do.

Alan Lenton points out that Hungarian may aid pattern recognition for the human user. I think this "aid to pattern recognition" is more beneficial for GUI "front-end" applications than for data-manipulative "back-end" applications. I said that scope identification was invaluable but type identification not. In practice, when studying or maintaining the code of others, I have found the lack of scope identification far more of a barrier to comprehension than the lack of type identification.

In regard to the bubble help and other visual cues that Alan mentions, it should be noted that the latest version of Microsoft's Visual C++ fulfils some of these tasks with its IntelliSense features. For example, it displays an identifier's type as a tool tip when you hover the mouse over it or type Ctrl+T.

Forgive me if I add a couple of comments.

It would be most unfortunate if the existence of an inferior solution to a problem prevented a better solution simply because the inferior one was widely used. C++ code suffers from this in many places. For example the widespread use of friend to support overloading operators (there are at least two better options). The widespread test for self-assignment in providing an operator=() is another that springs to mind. I believe we need to take every opportunity to campaign on behalf of better idioms.

Secondly I believe that using namespaces will go a long way to provide scope information in a way that allows that information to be omitted if the programmer thinks it unhelpful.