Applying Hungarian Notation to Java programs: Part 1

Wednesday Sep 8th 1999 by Greg Holmes

This naming convention for variables was originally meant for C code, but it has a lot to offer Java programmers everywhere.

Part 2 of this article will appear next week: Applying Hungarian Notation to Java programs: Part 2

Most Java programs could use better variable names!

Even the examples that come with the Java SDK from Sun could be improved, since many programmers are going to study them and learn from them. With so many classes and methods available to Java programs, it's important for source code to be as clear as possible.

Hungarian Notation can help.

Hungarian Notation (HN) is a naming convention that was originated years ago by Charles Simonyi of Microsoft and is used throughout the source code of the Windows operating system, among other places. The original specification is a bit complex and specific to the C programming language, but it can be successfully adapted to Java programs.

HN provides a way to make your code more understandable and maintainable by prefixing a variable name with its type. For example, if there is a numeric variable for a yearly total, it could be called nYearTotal. Another example: strUserName is probably a string variable that contains the User's name. Rocket science? I don't think so!

Another benefit of the original HN scheme is to facilitate a kind of "type calculus." This is especially useful in C where pointers, for example, are a notorious source of problems. If there is a variable x that is an integer representing a graphical coordinate and px is a pointer to such a coordinate, you can be fairly confident that the following C code is correct (at least as far as the compiler is concerned):

   x = *px;

Essentially, the * cancels the p.

But Java doesn't have pointers, so there is no need to create or de-reference them. However, Java's dynamic, object-oriented approach actually increases the need for a good naming convention, one that provides quite a bit of information about a variable just from its name.

As you will see, Hungarian Notation fills the bill.

The details

Variable names are made up of several parts, like this:

[scope] + type + Name + [qualifier]

In C, scope represents the visibility of the variable, such as global (visible to all routines) or local (visible only to the containing routine). The square brackets ([]) indicate that scope is not always present. The variable ghMainWindow could be a "global handle to the main window." In Java, scope is not an issue, because there are no global variables and everything belongs to one object or another (for example, the popular output stream object java.lang.System.out or the numeric constant java.lang.Math.PI).

Local variables in Java and C have no scope indicator prefixed to them, so this means that the scope indicator is rarely used in Java, except perhaps to indicate parameters, which I'll show you later.


The type indicates the data type or class of the variable; it is the heart of Hungarian Notation. It seems reasonable to use single-character prefixes for Java's primitive data types, but a little bit of imagination is required to work around the duplicate first letters.

Primitive Type     Set A     Set B     Set C  

My preference is for Set A, because it seems to be the best match of the primitive types, but you might want to reserve the s prefix for strings and use another letter for short, like n or t.

Creating type prefixes for classes is more difficult than for the primitive types. Simonyi's original specification stresses that the naming convention should not excessively increase the amount of typing, but the spec was created before object-oriented programming was common. In any case, you should try to come up with abbreviations for each class you use, perhaps three letters long.

 Class  Prefix 
 Button   btn
 Checkbox  chk
 Dialog   dlg
 Label   lbl

These prefixes seem to be fairly obvious, and that is probably because they are created from the dominant sound of the class name. If you say "Button" with a mouth full of chewing gum, you'll see what I mean.

Another way of generating prefixes is from the first few letters of the class name.

 Class  Prefix 
 Boolean   bool
 Record   rec
 Rectangle  rect
 String   str

The rec prefix seems to be more natural than rcd, although rec might be interpreted to mean Rectangle. I am quite happy to use rect for that, however.

And then there are the less obvious ones, where you have to get a bit more cryptic to create a prefix in three or four characters.

 Class  Prefix 
 InputStream   ins
 OutputStream  ous

I might use ins for any subclass of InputStream, such as ByteArrayInputStream, rather than trying to come up with a unique version like bais (which is based on the initial letters). Another possibility that is clearer than ins is istrm, but it might be getting a bit too long.

The abbreviations you use are up to you (and your programming team), but here are some rules of thumb you can try.

  1. Remove all vowels from the class name, then see if it still makes sense.
  2. Remove vowels, then remove other letters until just before it stops making sense.
  3. Fill your mouth full of chewing gum (or just cover it with your hand), say the class name, then try to represent the sound in three or four letters.

The most important thing is consistency, as the original HN spec points out.

Name and Qualifier

These make up the actual variable names that you've been creating all along, so there is nothing special here (e.g., UserName, MonthlyTotal, DataDir).

However, the original HN specification lists specific qualifier strings to use such as First, Last, Min, and Src. See "Program Identifier Naming Conventions", "Hungarian Naming Conventions", and "Greg Legowski's Guide to Hungarian Notation" for details.

Special prefixes

There are several special prefixes that I use. These are not part of the original Hungarian Notation specification, but they seem to work for Java code.

First there is o, which represents the generic Object class. This is useful in places where the exact type of the object is not known, such as in sorting routines or abstract classes. You can think of Object as being a primitive type, since all classes are descended from it.

Another special prefix is a, which stands for array. This prefix is added before other prefixes.

   long alRegionTotals[] = new long[4];

The third special prefix is p, which indicates a parameter to a method.

   public boolean isInside ( int piX, int piY )

You can see that the p prefix is always first, and in this case it appears before the i prefix (which indicates an integer). If an array is a parameter, then add the p to the beginning.

   public void resetRegionTotals ( long palTotals[] )

The p prefix helps you to decipher where a variable came from when you are looking at an unfamiliar method. (In this context, "unfamiliar" probably means something that you wrote six months ago. . .)

Here are some examples, with descriptions.

  • a boolean indicating completion status:
    bFinished = false;
  • today's date:
    dateToday = java.util.Date();
  • a String of legal hex digits:
    strHexDigits = "0123456789ABCDEF";
  • an array of Strings holding compass directions:
    astrDirection = {"N", "E", "S", "W"};
  • the Object that initiated the event:
    oSource = pEvent.getSource();
  • a two-dimensional array of numbers ("an array of arrays of integers"):
    aaiMatrix = {{1,2}, {3,4}, {5,6}};
  • a Button object:
    btnOk = new Button("Ok");
  • a Dialog box:
    dlgInfo = new InfoDialog(f, "Hello");

Like anything else, there are exceptions to the rule. Or perhaps, there are countless rules with differing degrees of strength that take precedence at different times. . . And here is an example of one of those rules: Variables with a smaller scope should generally have shorter names.

This means that loop counters, which typically only exist for a few lines or so, can have very short names. So short, in fact, that they do not comply with Hungarian Notation conventions.

   for(int j = 0; j < iMax; j++) {

The original HN specification also mentions x and y, which are commonly used as graphic coordinates and contain short integers.

Often parameters will be called something like p<type>, for example pEvent, where the type prefix has increased in significance (it is spelled out in full) to become the variable name. Similarly, you can use variable names like btn, o, and dlg. This relieves you of the need to make up a suitable name. If there is more than one variable of a certain type, you can add a number to the end, like btn1. But this sort of "nameless" variable tells you what but not why, so try to come up with a full name!


  1. "Meta-Programming: A Software Production Method"
    Author: Charles Simonyi
    Publisher: Stanford University, 1977 Doctoral thesis.
  2. "The Hungarian Revolution"
    BYTE, Aug. 1991 (vol. 16, no. 8)
    Authors: Charles Simonyi and Martin Heller
    Publisher: McGraw Hill
  3. Java Examples in a Nutshell
    September 1997, First Edition.
    Author: David Flanagan
    Publisher: O'Reilly & Associates
    ISBN: 1-56592-371-5
  4. "Program Identifier Naming Conventions"
    Author: Charles Simonyi
    A summary of the major ideas behind HN, with prefix listings.
  5. Article: "Programming, Hungarian Style" hungary.htm
    A short, lighthearted essay on one person's first exposure to HN.
  6. "Standards in Programming"
    Contains a useful list of common prefixes for visual programming objects, such as forms, buttons, and reports.
  7. "Jon Grover's version of Hungarian Notation for C++"
    Every letter of the alphabet is accounted for in this "relaxed" version!
  8. "Greg Legowski's Guide to Hungarian Notation"
    This page is a very readable summary of the "official" Hungarian Notation.
  9. "Hungarian Naming Conventions" archive/hungarian
    A shell archive (with nroff and ASCII text) that contains something closer to the original HN document. Shows how complex HN can be, but worth looking at.
  10. "Hungarian Notation"
    My short page that presents Hungarian Notation for CA-Clipper programs.

About the Author

Greg Holmes has been a freelance consultant since 1983 — GH Services. He has created information systems and provided client support and training in various programming languages. His specialties are mobile computing, data replication, client-server technologies, and sensible user-interface design. He was a founding member of CDAT — the Clipper Developers Association of Toronto, and was the original editor of "The Navigator" (CDAT's newsletter). He was a member of the CDAT Executive since the Association's inception in May of 1989 until 1993. He can be reached at

Go to Part 2 of this article: Applying Hungarian Notation to Java programs: Part 2

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved