Title: Comments on Hungarian Type Notations

I feel impelled to comment on debate between the Harpist and others about Hungarian Notation (and indeed other conventions of this nature).

There are a number of points to note. The first is that this controversy is not accidental, trivial, or incidental. It goes to the very heart of program debugging technique. That is why it raises so many passions and refuses to go away.

Programming is a purely intellectual exercise. When a program is broken, you don't go down to the program shop and buy a spare part (well sometimes you have to obtain a 'fixed' component. Francis), you sit down and use your intellectual abilities to figure out what is wrong and fix the problem. This means that anything that interferes with or aids that mental concentration is important.

Above everything else the human brain is a pattern-matching machine. If the code you are looking at is a regular pattern (in content as well as layout) then things that break that pattern will stand out. If on the other hand the code layout and logic is a shambles then there is no way you can spot something out of the ordinary.

Make no mistake - bugs are fixed by looking at code. Debuggers and other tools may tell you which section of code to look at, but the bug itself is always found by looking at the code!

It is this pattern matching ability - both logic patterns and syntax patterns - that underlies all the strictures about coding standards - even if the authors don't realise why they are advocating such things.

For instance, there is nothing intrinsically wrong with GOTOs - all the founding fathers of computer programming not withstanding - the compiler uses them all the time in the machine code it generates. The reason we don't use them has nothing to do with their intrinsic worth, it is because they break up the logic of the program making it impossible to spot logic pattern defects.

All of the proposed 'notations' have one thing in common. They are designed to make the underlying pattern more visible. This is a laudable objective, so why then do they come in for so much vilification? And why do they have such fervent admirers?

The problem is that one man's meat is another man's poison. Different people see the same pattern differently and use different visual cues to decompose patterns. For one person, code written in Hungarian Notation may make all the difference between being able to see a pattern and not being able to see it. For another, the same notation may completely obscure the pattern.

Neither of these people are 'right' or 'wrong', they are simply different - which is not unusual! The real problem here is that one person's pattern analysis cues are being embedded in the program, obfuscating it for those who use a different set of pattern cues.

The solution is not to embed visual cues in the code but to have editors that will embed your own set of cues in the code when they display it to you. Of course the problem is that none of the present generation of code editors have these facilities.

When I load code into an editor I don't need to be identify keywords by having them in green; 'C' and 'C++' have a very small set of keywords which are easy to remember - I want to be able to tell the editor to put all class member data in green. And furthermore, I want to turn this on and off without leaving the screen with the code on it!

I want to put the cursor on the variable and have the bubble help tell me that it is an integer, or whatever, if I need the information. (If only life came with bubble help!)

The point is that I want to add my visual cues, I don't want to be burdened with other people's cues. Debugging is a difficult enough activity without other people clogging up my pattern space with their aide-memories!

Yes - I want it all, and I want it now - Microsoft, Borland, Symantic et al take note!

One of the problems with the notations (Hungarian etc.) that Alan is referring to is that, like comments, they go out of date and we are matching erroneous patterns.

I think his suggestion on the use of colour and bubble help (with a spoken option for those with sight problems) is exactly what we need. Now that C++ has stabilised (I know C is about to change, but the changes are much smaller than for C++) any company focussing on this aspect of editors must be on to a winner.

I hope it will not be long before someone does this. Actually CodeWarrior is getting close on the colour side. Francis