I have bones to pick with some of Simonyi's other ideas, but H.N. is actually good. I'd go so far as to say that if you understand it and apply it properly, it is one of the best text-code notations possible. BUT NOT BECAUSE IT TELLS PROGRAMMERS THE VARIABLE'S TYPE; that's nearly irrelevant.
The REAL purpose--if you read Simonyi's Ph.D thesis--is to piggy-back off of the already unique names of types in order to avoid having to give variables names and let the name be provided by context! If you are writing a routine that destroys a window:
void DestroyWindow(HWND );
Wouldn't you ideally like to omit the name of the variable? Isn't it obvious what it does? Calling it "HWND TheWindowToBeDestroyed" is clutter and just makes the source look like a mess.
But the compiler forces you to give variables a name, that's the way it is. Calling it noname12314 is okay from a technical point of view, but programmers can't decode that. Fully Hungarianized names, such as:
HWND hwnd;
HWND* phwnd;
HWND rghwnd[3];...communicate to any Hungarian-ized programmer reading the source that these variables don't have unique names. They are essentially nameless, their meaning supplied by the context. Instead of giving them random strings (like "x") which could cause people to scratch their heads with all the possible associations ("why call it x? is it a variable we are solving for, like in an equation?") it at least carries along one fairly useful piece of information (the type).
But the type is just a side benefit. If you can't think of a name that does more good than harm, it saves you from naming. Of course Hungarian also has a way to encode useful information if you think of it: this is what the suffix is for, e.g. if you have two HWND variables you *must* discriminate somehow:
HWND hwndTopmost;
HWND hwndUnderTopmost;
(even though "hwnd" is free in the scope, they couldn't
both
be called "hwnd"!)
It's rather depressing that even within Microsoft, nobody gets it; like any other tool, it wreaks havoc in the hands of the ignorant. (Just look at the Windows APIs themselves, they don't get it at all! No wonder Hungarian Notation has such a bad rap.)
Slashdot Mirror
The REAL purpose--if you read Simonyi's Ph.D thesis--is to piggy-back off of the already unique names of types in order to avoid having to give variables names and let the name be provided by context! If you are writing a routine that destroys a window:
void DestroyWindow(HWND );
Wouldn't you ideally like to omit the name of the variable? Isn't it obvious what it does? Calling it "HWND TheWindowToBeDestroyed" is clutter and just makes the source look like a mess.
But the compiler forces you to give variables a name, that's the way it is. Calling it noname12314 is okay from a technical point of view, but programmers can't decode that. Fully Hungarianized names, such as:
HWND hwnd;
HWND* phwnd;
HWND rghwnd[3];
But the type is just a side benefit. If you can't think of a name that does more good than harm, it saves you from naming. Of course Hungarian also has a way to encode useful information if you think of it: this is what the suffix is for, e.g. if you have two HWND variables you *must* discriminate somehow:
HWND hwndTopmost;
HWND hwndUnderTopmost;
(even though "hwnd" is free in the scope, they couldn't
- both
be called "hwnd"!)It's rather depressing that even within Microsoft, nobody gets it; like any other tool, it wreaks havoc in the hands of the ignorant. (Just look at the Windows APIs themselves, they don't get it at all! No wonder Hungarian Notation has such a bad rap.)