Hungarian works for me. No doubt you’ve seen this convention used sometimes, sort of, in some code contained in Visual Basic samples and documentation. I don’t claim that this convention is better than other naming conventions or that it doesn’t have problems. But I’ve used Hungarian in various languages (including, believe it or not, FORTRAN), and it applies well to Visual Basic.
I’m not trying to evangelize Hungarian. Everyone I know who uses it (including me) hated it at first. It just grows on you. Maybe it will grow on you enough to make you a convert during the course of this book—or maybe it won’t. In any case, being able to read Hungarian is a skill you won’t regret acquiring. If you haven’t really understood the point of the snippets of Hungarian code you have seen in various Microsoft manuals, here’s a brief introduction that will make reading the sample code easier.
Long-time Microsoft developer Charles Simonyi, who happens to be Hungarian by birth, developed the convention. That—along with the fact that C code written in this style looks like foreign gibberish to the uninitiated—prompted the name. The idea (simplified to a point that would probably horrify Simonyi) is that variables should consist of two parts: a lowercase base type indicating the kind of variable and an initial-cap qualifier that distinguishes this variable from others of the same kind.
For example, an integer that keeps track of the file position would have the base type i for index and the qualifier Pos to form the variable iPos. If you must keep track of both a file position and a line position in the same context, you need to qualify further: iFilePos and iLinePos. If you were creating a Project Save As dialog box, you might call it FProjectSaveAs and fill it with controls such as cboFiles, cboDirs, lstFileTypes, lstDrives, cmdOk, cmdCancel, and cmdNetwork. If you had an array of buttons to activate different windows, the base type cmd wouldn’t be enough, so you could modify it with the array prefix a, as in acmdWindow. To access this array, you might need a count variable showing the number of windows, cWindow, and an index to the current window, iWindowCur. In a small function using only one local index variable, you don’t need a qualifier—just call it i.
This doesn’t begin to touch on the complexity of the original Hungarian convention. In addition, the whole idea has been bastardized. At least three incompatible official dialects of Hungarian are used by C programmers at Microsoft, and now the Visual Basic documentation group has introduced their own variation of Hungarian. Unfortunately, the crudest of these variations is the one used in the Windows Software Development Kit (SDK), and it is now spreading confusion to the world. In a few short years, the Hungarian coding convention has evolved as much as natural languages evolve in a thousand years.
Compare, for example, the naming convention in the Windows SDK Help file with the one in the Visual Basic API Help file shipped with Visual Basic version 3. (If you don’t remember version 3, never mind.) Both files are aimed at C programmers—the first at those writing Windows-based programs in C, and the second at those writing VBX controls in C. You’d expect both files to use the same convention, but the names for similar variables are in fact very different, although both systems are vaguely recognizable as Hungarian.
In the SDK, for example, a Boolean variable has the prefix b for Boolean. In the Visual Basic API, a Boolean variable has the prefix f for flag. In the SDK, a variable used as a bit flag has the prefix w or dw for Word or DWord, indicating its type—or at least the Windows include file version of its type. In the Visual Basic API, a similar variable has the prefix fs or fl for flag of short or flag of long, respectively, indicating both its use and its type. This goes on. Windows SDK names sometimes indicate the use of the variable, but more often they simply indicate the data type, and even then in an artificial form that has no relation to Basic (or to C, for that matter).
Alas, the version of Hungarian used in the Visual Basic documentation is a cousin of the Windows version. It uses prefixes based on the types (lng for Long, str for String, sng for Single, and so on). Worse, it uses generic prefixes for different kinds of multimember types rather than specific prefixes for each type. For example, you’ll see frm for all forms, cls for all classes, and udt for all user-defined types. I invented my version of Hungarian before all the others, so don’t ask me to copy them.