Hungarian notation is a computer programming technique. It is a method of naming identifiers in source code. Identifier here means mostly variable names, but really refers to anything in the program that you need to name: variables, constants, functions, classes etc. A prefix is pretended onto the variable name to indicate the intended type and scope of the variable.
Hungarian notation encodes type information into variable names
Hungarian notation was developed by ace computer programmer Charles Simonyi. According to one source he started coding like this in early 1970s while working for Xerox PARC. However he joined Microsoft in 1981 and was senior programmer for "more than a decade". During this time his naming convention became better known.
Since his co-workers couldn't pronounce "Simonyi notation" they named it after his nationality, and after the way in which the resulting variable names resemble some foreign east-European language with not enough vowels more than they do plain English. (Assuming that you are English-speaking. No offence meant if you speak plain Hungarian and find English bizarre and counterintuitive). The name is also joking reference to reverse polish notation.
The system is designed to make variable names contain more information, so that a programmer can tell at a glance that lpszName is a "long pointer to a null-terminated string described as "name".
It is also meant to standardise and simplify the naming of local scratch variables, for which the prefix may be all the variable name that is needed (see "i" is a meaningful variable name
)
In Simonyi's original paper "Program Identifier Naming Conventions" he outlines four benefits of his identifier naming convention:
1. Mnemonic value: The programmer will remember the name as it is constructed logically not whimsically or randomly.
2. Suggestive value: The name will help others understand the use of the variable on reading the code. Variable names can only help a little, but do not underestimate the importance of readable (i.e. maintainable) code.
3. Consistency: The names used throughout the program will be consistent, as they will have been produced by the same rules.
4. Speed of the decision: When naming variables, the variable name decision will be mechanical and thus quick.
As with most conventions (e.g. on which side of the road to drive), there is no one right way to do things, however the people who must work together all benefit if they can all agree on a common standard. The number of people working together can be as low as two programmers on a project, but could be all programmers working with an operating system API. Considering that Hungarian notation is used on the Windows API, this is indeed a large number of people.
This system became widely used inside Microsoft. The Hungarian naming convention is quite useful—it's one technique among many that helps programmers produce better code faster.
Perhaps the most important publication that encouraged the use of Hungarian notation was the first book read by almost every Windows programmer: Charles Petzold's Programming Windows. It used a dialect of Hungarian notation throughout and briefly described the notation in its first chapter.
Hungarian notation is rather out of favour with many programmers who have never grokked it. The prefixes are refered to as warts. To a programmer this is a fairly obvious term - the prefix is the ugly lowercase protrusion before the first capital letter in the variable name.
This distrust is strongest in non-Microsoft aligned circles. This may be due to mistrust of its originating company. This reason is in my opinion foolish. Microsoft wouldn't be big without doing some things right, and it is well-documented that they do use their wealth to hire talented programmers such as Charles Simonyi. Don't judge ideas by Ad-hominem standards.
Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack.
- How to write unmaintainable code
The other reason is that the Hungarian notation system in all its detail is seen as inflexible, over complex and unreadable. "What happens when I change my short int to a long int?" cries the C programmer. "That shouldn't necessitate a variable name change!"
Also the names can become very long for e.g. the name g_ppllarrPixels is typed as "global pointer to a pointer to an array of LONGLONG structures containing pixels" But then again, if you really have a data structure like that, you are in fact doing something really complex in a low-level language and perhaps need to be reminded of that.
Hungarian notation can refer to systems that range between two extremes
- In most specific, the system for C and C++ programs as initiated by Charles Simonyi and detailed within Microsoft.
- In most general, any scheme that prefixes variable names with characters representing type and scope.
My own personal Hungary
I don't favour Hungarian notation in the first meaning in my code. I can't anyway, I'm not coding in C/C++.
I do favour the second, for much the reason that Hungarian notation was proposed in the first place: It makes code more readable.
I get around the C programmer's objection by not distinguishing between different integral types (or other similar types) – When reading code, it doesn't often matter if the int is long or short, but it matters a lot if the variable is an int or a string. If you are changing an int variable into a string variable, that is a big enough change that you probably do want to change the variable name anyway, in order to look at everywhere it is being used. (I work in a strongly typed language).
I try to keep it simple. A multi-page specification of multiple levels of prefixing will take a lot of time to specify and to use, and thus is not recommended unless you feel like being anal, bureaucratic and counterproductive.
I like to use two characters in the variable name prefix.
The first character represents variable scope:
P = parameter to current routine
L = local to current routine
G = global to program
M = global to the module
F = private or protected field on current object or record
The second character represents data type
B = Boolean
I = integer
S = string
F = float
C = object (class) type
P = pointer
Etc.
You can't find a prefix for every type in an object-oriented language, so cease striving for completeness, hit the common ones, make defaults (e.g. 'e' = any enumerated type) and move on to more important problems.
So at a glance, I can tell a lot about code like
if lbStatusOK then
fcNames[liIndex] := psNewName;
It's not complex, nor inflexible. And it makes code more readable.
Sources: Microsoft website, kuro5hin, other websites via google, own experience.
IMHO pfft is dead wrong. Variable declaration and variable use could be separated by 1000 or more lines of code. Local information is very helpful.