Hungarian Notation

Excerpt from pages xxvii-xxxi of
John Paul Mueller: Visual C++ 5 from the Ground Up
(Osborne/McGraw-Hill 1997)


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:

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