Title: Hungarian Notation- Another View

Hungarian notation is one of those ideas used in software development that is either loved or hated. Having been a commercial software developer for a few years now, almost exclusively with Microsoft development tools, I thought I would add a few comments to this topic.

The purpose of Hungarian notation is to make it easier for a human to read code by providing immediate feedback of an identifier's type at any place in the code. Before asking whether it achieves this objective it can be admitted immediately that the major disadvantage of this is that it ties an identifier's name to its type so that a change in the latter forces a change in the former. This introduces a problem of code maintenance, though I don't think this is quite so serious these days given the editing facilities of current development tools.

But does Hungarian notation really make it easier to read code? Many would answer that it does not, and that, in fact, it makes it harder. My own view is that it does not particularly make it harder to read, especially once you've got used to it. (Whether it makes it easier to read is another matter.) The difficulty is more to do with applying it consistently and remembering the often lengthy prefixes (e.g., "lpsz").

Before putting forward my own views on the merits or demerits of Hungarian notation here is the policy I adopt towards it in practice.

In general, I tend to fall in with the style of whatever code I have to interface with. So if I'm using Microsoft C++, especially MFC, and have to use Wizard-generated code then my extensions to such code tend to adopt Hungarian so that the code looks "integrated."

If I'm doing maintenance work on code that's not written by me I tend to adopt the notation of the original author. If he uses Hungarian then I do. If he doesn't then I don't. If I'm writing completely separate routines I may relax this and stick to my own approach. This all assumes that there are no mandated coding guidelines in force. In my experience, in regard to the use of Hungarian, there usually aren't.

Now what do I think of Hungarian notation?

I think it is helpful but only to a certain extent. I think it is helpful in regard to user interface widgets. For example, it is very helpful to adopt it when referring to such things as list boxes, buttons, tree view nodes, etc. But for simple data types and objects that are not user interface widgets, I think only a very restricted subset of Hungarian is necessary for readability.

In C++, it is helpful to adopt a convention such as using the prefixes, "p" for a pointer, "m_" (or something similar) for a class data member, perhaps "g_" for a global identifier, perhaps "s_" for a static identifier. In addition it can be helpful to adopt a convention for strings, where string objects and C-style strings are being used together. So, maybe, a "str" prefix for a string object and an "sz" prefix for a C-style null-terminated string. And that's about it.

In Visual Basic, I adopt Hungarian for the UI widgets and not for anything else. (If I have to use class modules then I follow my C++ approach for data members and that's it.)

In practice, I'm not particularly fussed about extensions to Hungarian notation beyond what I've outlined but I feel that they do not add anything further to readability.

I handed this to the Harpist for his view and this is what I got back.

There are several issues that should be considered when discussing notations such as HN. Kevin has already touched on the first when he mentions the problem of tracking changing type information. He also mentions the problem of readability.

On the other hand there is some advantage in tracking the purpose of an identifier even if we avoid the inclusion of type specific coding. Kevin implicitly uses such when he prepends m_ or g_ to an identifier.

To be honest, until recently I considered such elaboration of identifiers to be silly. However I do read and try to learn from the experiences and ideas of others. There is a real advantage in using some coding convention to distinguish the scope of an identifier, it helps to limit damage caused by unintended name hiding. This can become a serious issue in C++ where we need to be concerned with name hiding and how it interacts with function overloading.

I want to take this opportunity to suggest an alternative set of naming conventions that is less invasive while meeting most of the more desirable objectives. My guidelines are:

Do not use prefixes. They get in the way of readability. Use a suffix (i.e. append the elaboration).

Do not include specific type information. Only include context and use information.

Only use any kind of elaboration in large projects.

Ensure that all members of a project team are committed to the same scheme.

A few examples:

I think that is enough to start with. Perhaps readers would like to give their reactions.