Hungarian Notation is a way of telling other people, what you intend to do with a variable. Knowing, what a variable is supposed to do, can often help explain the code itself. For example, if I tell you, that a particular variable contains a handle to a window, then you know a lot more about it, than the fact, that it is simply a variable. You can interpret the code surrounding that variable with the understanding, that it's supposed to do something with a window.
The first stage of development for this variable-naming system was started by Hungarian programmer Charles Simonyi (Simonyi Károly) of Microsoft Corporation. He called his system Hungarian Notation. A copy of his work can be found on BBSs, some Microsoft programming websites, CompuServe, etc. Simonyi's work was further enhanced by other developers. For example, Xbase programmers use their own special version of Hungarian Notation. It takes into account the different types of variables that Xbase provides. An enhanced Xbase version of Hungarian Notation was published by Robert A. Difalco of Fresh Technologies. You can find his work on a few DBMS-specific BBSs as well as the Computer Associates forum on CompuServe. There are 4 reasons why you should use Hungarian Notation in your programs:
- mnemonic value
- suggestive value
- consistency
- speed of decision
Rule 1: Prefixing a Variable
Always prefix a variable with one or more lowercase letters indicating its type! In most cases this is the first letter of the variable type, so it's easy to remember what letter to use. The following examples show the most common prefixes for Visual BASIC, Delphi and C. (There are literally hundreds of combinations used in Windows that don't appear here.) You'll also see a few database-specific indentifiers provided here:
a c d dbl dc dw f h i inst l li lp msg n o pal psz ptr (p when used with other variables like psz) r rc rgb rsrc sgl si sz u ui w wnd array character date double device context double word flag (Boolean or logical) handle integer instance long long integer long pointer message numeric object palette pointer to a zero-terminated string pointer real rectangle red, green, blue (color variable) resource single short integer zero-terminated string unsigned unsigned integer or byte word window
Rule 2: Identifying State Variables
Some variables represent the state of an object like a database, a field or a control. They might even store the state of another variable. Telling other programmers that a variable monitors the current state of an object can help them see its significance within the program. You can identify state variables using one of the following three-character qualifiers:
New Sav Tem a new state a saved state a temporary state
Rule 3: Using a Standard Qualifier
A standard qualifier can help someone see the purpose of a variable almost instantly. This isn't the type of information that the variable contains, but how it reacts with other variables. For example, using the Clr qualifier tells the viewer that this variable is used in some way with color. You can even combine the qualifiers to amplify their effect and describe how the variable is used. For example, cClrCrs is a character variable that determines the color of the cursor on the display. Using one to three of these qualifiers is usually sufficient to describe the purpose of a variable. The following standard qualifiers are examples of the more common types:
Ar Attr B Clr Col Crs Dbf f File Fld L Msg Name Ntx R Rec Ret Scr Str T X Y array attribute bottom color column cursor database file first file field last/left message name index file right record number return value screen string top row column
Rule 4: Adding Descriptive Text
Once you clearly define the variable's contents and purpose, you can refine the definition with some descriptive text. For example, you might have a long pointer to a string containing an employee's name that looks like this: lpszEmpName. The first two letters tell you that this is a long pointer. The second two letters tell you that this is a zero-(or null-)terminated string. The rest of the letters tell you that this is an employee name. Seeing a variable name like this in a piece of code tells you what to expect from it at a glance.
Rule 5: Creating More, Than One Variable
There are times when you won't be able to satisfy every need in a particular module using a single variable. In those cases you might want to create more, than one of that variable type and simply number them. You could also designate its function using some type of number indicator like those shown next:
1,2,3 Max Min Ord state pointer references as in cSavClr1, cSavClr2, etc. strict upper limit as in nFldMax, maximum number of fields strict lower limit as in nRecMin, minimum number of records an ordinal number of some type