Hungarian notation is an identifier naming convention in computer programming in which the name of a variable or function indicates its intention or kind, or in some dialects, its type. The original Hungarian notation uses only intention or kind in its naming convention and is sometimes called Apps Hungarian as it became popular in the Microsoft Apps division in the development of Microsoft Office applications. When the Microsoft Windows division adopted the naming convention, they based it on the actual data type, and this convention became widely spread through the Windows API; this is sometimes called Systems Hungarian notation.
Hungarian notation was designed to be language-independent, and found its first major use with the BCPL programming language. Because BCPL has no data types other than the machine word, nothing in the language itself helps a programmer remember variables' types. Hungarian notation aims to remedy this by providing the programmer with explicit knowledge of each variable's data type.
In Hungarian notation, a variable name starts with a group of lower-case letters which are mnemonics for the type or purpose of that variable, followed by whatever name the programmer has chosen; this last part is sometimes distinguished as the given name. The first character of the given name can be capitalized to separate it from the type indicators (see also CamelCase). Otherwise the case of this character denotes scope.
The original Hungarian notation was invented by Charles Simonyi, a programmer who worked at Xerox PARC circa 1972–1981, and who later became Chief Architect at Microsoft. The name of the notation is a reference to Simonyi's nation of origin, and also, according to Andy Hertzfeld, because it made programs "look like they were written in some inscrutable foreign language".[1] Hungarian people's names are "reversed" compared to most other European names; the family name precedes the given name. For example, the anglicized name "Charles Simonyi" in Hungarian was originally "Simonyi Károly". In the same way, the type name precedes the "given name" in Hungarian notation. The similar Smalltalk "type last" naming style (e.g. aPoint and lastPoint) was common at Xerox PARC during Simonyi's tenure there.
Simonyi's paper on the notation referred to prefixes used to indicate the "type" of information being stored. His proposal was largely concerned with decorating identifier names based upon the semantic information of what they store (in other words, the variable's purpose). Simonyi's notation came to be called Apps Hungarian, since the convention was used in the applications division of Microsoft. Systems Hungarian developed later in the Microsoft Windows development team. Apps Hungarian is not entirely distinct from what became known as Systems Hungarian, as some of Simonyi's suggested prefixes contain little or no semantic information (see below for examples).
Where Systems notation and Apps notation differ is in the purpose of the prefixes.
In Systems Hungarian notation, the prefix encodes the actual data type of the variable. For example:
lAccountNum : variable is a long integer ("l");arru8NumberList : variable is an array of unsigned 8-bit integers ("arru8");bReadLine(bPort,&arru8NumberList) : function with a byte-value return code.strName : Variable represents a string ("str") containing the name, but does not specify how that string is implemented.Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.
rwPosition : variable represents a row ("rw");usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.Most, but not all, of the prefixes Simonyi suggested are semantic in nature. To modern eyes, some prefixes seem to represent physical data types, such as sz for strings. However, such prefixes were still semantic, as Simonyi intended Hungarian notation for languages whose type systems could not distinguish some data types that modern languages take for granted.
The following are examples from the original paper:[2]
p''X'' is a pointer to another type X; this contains very little semantic information.''d'' is a prefix meaning difference between two values; for instance, dY might represent a distance along the Y-axis of a graph, while a variable just called y might be an absolute position. This is entirely semantic in nature.''sz'' is a null- or zero-terminated string. In C, this contains some semantic information because it is not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero-terminated string.''w'' marks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian.''b'' marks a byte, which in contrast to w might have semantic information, because in C the only byte-sized data type is the char, so these are sometimes used to hold numeric values. This prefix might clear ambiguity between whether the variable is holding a value that should be treated as a character or a number.While the notation always uses initial lower-case letters as mnemonics, it does not prescribe the mnemonics themselves. There are several widely used conventions (see examples below), but any set of letters can be used, as long as they are consistent within a given body of code.
It is possible for code using Apps Hungarian notation to sometimes contain Systems Hungarian when describing variables that are defined solely in terms of their type.
In some programming languages, a similar notation now called sigils is built into the language and enforced by the compiler. For example, in some forms of BASIC, name$ names a string and count% names an integer. The major difference between Hungarian notation and sigils is that sigils declare the type of the variable in the language, whereas Hungarian notation is purely a naming scheme with no effect on the machine interpretation of the program text.
bBusy : BooleanchInitial : charcApples : count of itemsdwLightYears : double word (Systems)fBusy : flag (or float)nSize : integer (Systems) or count (Apps)iSize : integer (Systems) or index (Apps)fpPrice : floating-pointdecPrice : decimaldb[[Pi]] : double (Systems)p[[Foo]] : pointerrgStudents : array, or rangeszLastName : zero-terminated stringu16Identifier : unsigned 16-bit integer (Systems)u32Identifier : unsigned 32-bit integer (Systems)stTime : clock time structurefnFunction : function nameThe mnemonics for pointers and arrays, which are not actual data types, are usually followed by the type of the data element itself:
pszOwner : pointer to zero-terminated stringrgfpBalances : array of floating-point valuesaulColors : array of unsigned long (Systems)While Hungarian notation can be applied to any programming language and environment, it was widely adopted by Microsoft for use with the C language, in particular for Microsoft Windows, and its use remains largely confined to that area. In particular, use of Hungarian notation was widely evangelized by Charles Petzold's "Programming Windows", the original (and for many readers, the definitive) book on Windows API programming. Thus, many commonly seen constructs of Hungarian notation are specific to Windows:
wParam (word-size parameter) and lParam (long-integer parameter) for the WindowProc function.hwndFoo : handle to a windowlpszBar : long pointer to a zero-terminated stringThe notation is sometimes extended in C++ to include the scope of a variable, optionally separated by an underscore.[3] [4] This extension is often also used without the Hungarian type-specification:
g_nWheels : member of a global namespace, integerm_nWheels : member of a structure/class, integerm_wheels, _wheels : member of a structure/classs_wheels : static member of a classc_wheels : static member of a functionIn JavaScript code using jQuery, a $ prefix is often used to indicate that a variable holds a jQuery object (versus a plain DOM object or some other value).[5]
(Some of these apply to Systems Hungarian only.)
Supporters argue that the benefits of Hungarian Notation include:
btn might find all the Button objects.Most arguments against Hungarian notation are against Systems Hungarian notation, not Apps Hungarian notation. Some potential issues are:
a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.... nowadays HN and other forms of type encoding are simply impediments. They make it harder to change the name or type of a variable, function, member or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader.[8]
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.[9]
Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check.[10]
No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.[11]
If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that'''us'''meant unsafe string and'''s'''meant safe string. They're both of type'''string'''. The compiler won't help you if you assign one to the other and Intellisense [an [[intelligent code completion]] system] won't tell you bupkis. But they are semantically different. They need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky. There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong.... (Systems Hungarian) was a subtle but complete misunderstanding of Simonyi’s intention and practice.[12]