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 three lower-case letters which are mnemonics for the type or purpose of that variable, followed by whatever the name the programmer has chosen; this last part is sometimes distinguished as the given name. The first character of the given name can be capitalised to separate it from the type indicators (see also CamelCase). Otherwise the case of this character denotes scope.
The notation is an ironic reference to Simonyi's nation of origin; 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 rather than the more natural, to most Europeans, Smalltalk "type last" naming style e.g. aPoint and lastPoint. This latter naming style was most common at Xerox PARC during Simonyi's tenure there. It may also be inspired by play on the name of an almost entirely unrelated concept, Polish notation.
The name Apps Hungarian was coined since the convention was used in the applications division of Microsoft. Systems Hungarian developed later in the Microsoft Windows development team. Simonyi's paper 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), consistent with Apps Hungarian. However, his suggestions were not entirely distinct from what became known as Systems Hungarian, as some of his suggested prefixes contain little or no semantic information. (See below for examples.)
The term Hungarian notation is memorable for many people because the strings of unpronounceable consonants vaguely resemble the consonant-rich orthography of some Eastern European languages despite the fact that Hungarian is a Finno-Ugric language, and unlike Slavic languages is rather richer in vowels. For example the zero-terminated string prefix "sz" is also a letter in the Hungarian alphabet (cf. the Eszett 'ß' from German).
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");
szName: variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
Apps Hungarian notation doesn't encode the actual data type, but rather, 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)
strName: Variable represents a string ("str") containing the name, but does not specify how that string is implemented.
Most, but not all, of the prefixes Simonyi suggested are semantic in nature. The following are examples from the original paper:
pXis a pointer to another type X; this contains very little semantic information.
dis 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.
szis a null- or zero-terminated string. In C, this contains some semantic information because it's not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero-terminated string.
wmarks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian.
bmarks 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 letter (or more generally 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.
name$names a string and
count%names an integer, and in Perl,
$namerefers to a scalar variable while
@namelistrefers to an array. Sigils have the notable advantages over Hungarian notation that they implicitly define the type of the variable without need for redundant declaration, and are also checked by the compiler, preventing omission and misuse.
On the other hand, such systems are in practice less flexible than Hungarian notation, typically defining only a few different types — the lack of adequate easy-to-remember symbols obstructs more extensive use. In addition, although it has not been done, it is feasible to construct a static-checking tool which could statically verify the presence and correctness of Hungarian prefixes.
cApples: count of items
dwLightYears: double word (systems)
fBusy: boolean (flag)
nSize: integer (systems) or count (application)
iSize: integer (systems) or index (application)
dbPi: double (systems)
rgStudents: array, or range
szLastName: zero-terminated string
u32Identifier: unsigned 32-bit integer (systems)
stTime: clock time structure
fnFunction: function name
The 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 string
rgfpBalances: array of floating-point values
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. Thus, many commonly-seen constructs of Hungarian notation are specific to Windows:
hwndFoo: handle to a window
lpszBar: long pointer to a zero-terminated string
g_nWheels: member of a global namespace, integer
m_nWheels: member of a structure/class, integer
m_wheels: member of a structure/class
s_wheels: static member of a class
_wheels: local variable
btn<Ctrl-Space>causes the editor to pop up a list of Button objects.
usmeant “unsafe string” and
smeant “safe string.” They’re both of type
string. The compiler won’t help you if you assign one to the other and Intellisense 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.