Hungarian notation

From Wikipedia, the free encyclopedia

1 History
2 Systems vs. Apps Hungarian
3 Relation to sigils
4 Examples
5 Criticisms
6 References
7 External links

Hungarian notation is a naming convention in computer programming, in which the name of an object indicates its type or intended use. There are two types of Hungarian notation: Systems Hungarian notation and Apps Hungarian notation.

It 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 one or more 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.

[edit] History

The original Hungarian notation, which would now be called Apps Hungarian, was invented by Charles Simonyi, a programmer working at Xerox, who later became Chief Architect at Microsoft.

The notation is named for 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 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, not a Slavic, language, and so is rather richer in vowels. For example the zero-terminated string prefix "sz" is also a letter in the Hungarian alphabet (think the Eszett 'ß' from German).

[edit] Systems vs. Apps Hungarian

Where Systems notation and Apps notation differ is in the purpose of the prefixes.

In Systems Hungarian notation, the most common form, the prefix encodes the actual data type of the variable. For example:

ulAccountNum : variable is an unsigned long integer
szName : variable is a zero-terminated string; 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
usName : variable represents an unsafe string, which needs to be translated by some function to make it safe (e.g. see Cross site scripting)
strName : Variable represents a string containing the name, but does not specify how that string is implemented.

While most of the prefixes Simonyi suggested are semantic in nature, not all are. The following are examples from the original paper:^[1]:

pX 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's not clear whether a variable of type char* is a pointer to a single character or an entire 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 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.

[edit] Relation to sigils

In some programming languages, a similar notation now called sigils is built into the language and enforced by the compiler. For example, in BASIC, name$ names a string and count% names an integer, and in Perl, $name refers to a scalar value while @namelist refers to a list of values. 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 an adequate number of different 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.

[edit] Examples

bBusy : boolean
cApples : count of items
dwLightYears : double word (systems)
fBusy : boolean (flag)
nSize : integer (systems) or count (application)
iSize : integer (systems) or index (application)
fpPrice: floating-point
dbPi: double (systems)
pFoo : pointer
rgStudents : array, or range
szLastName : zero-terminated string
u32Identifier : unsigned 32-bit integer (systems)
stTime : clock time structure

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

The notation is sometimes extended in C++ to include the scope of a variable, separated by an underscore:

m_nWheels : member of a class, integer

[edit] Criticisms

(These mainly apply to Systems Hungarian only.) Supporters argue that the benefits include:^[1]

The variable type can be seen from its name
Variable names can be easy to remember from knowing just their types.
It leads to more consistent variable names
Deciding on a variable name can be a mechanical, and thus quick, process
Inappropriate type casting and operations using incompatible types can be detected easily
Useful with string based languages where numerics are strings (TCL for example)
In Apps Hungarian, the variable name guards against using it in an improper operation with the same data type by making the error obvious as in:

heightWindow = window.getWidth()

Whilst critics argue that:

It encourages the use of poor naming practices. For example it becomes confusing when it is used to represent several properties, as in:

a_crszkvc30LastNameCol : constant reference function argument, holding contents of a database column of type varchar(30) called LastName that was part of the table's primary key

It is inconsistent with code portability since the variable name is tied to the type. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. It was originally a 16 bit type, but was changed to a 32 bit or 64 bit type in later versions of the operating system but retained its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer).
It dramatically reduces readability for those unfamiliar with the notation
Modern Integrated development environments will automatically flag operations which use incompatible types, and display variable types on demand; making the notation obsolete.
It may lead to inconsistency when code is modified. If a variable's type is changed, its name may reflect the previous type leading to confusion.

The .NET Framework, Microsoft's new software development platform, lacks Hungarian notation completely; the .NET Framework Guidelines advise programmers that it should not be used. ^[2]