Class prefixes
Variable naming conventions are one thing; type naming conventions are another. You can define several kinds of types in Basic, including forms, classes, controls, global modules, enums, and user-defined types. Like other types, they are essentially templates that define the features of the type. I start my type
names with an uppercase letter. Table 1-3 shows the different kinds of types and my prefixes for them. I end up with type names like these: CDrive, FGetColor, and ESortType.
|
Prefix |
Type |
|
C |
Class |
|
F |
Form |
|
T |
User-defined type |
|
X |
ActiveX control |
|
D |
ActiveX document |
|
P |
Property page |
|
E |
Enum |
|
I |
Interface class for Implements |
|
G |
Global object class module |
|
M |
Standard module |
Table 1-3. Hardcore Hungarian for types.
FLAME User-defined type must be the worst name ever given to a major language feature. Why couldn’t the QuickBasic developers who added this feature have given it a one-word name? If you borrow features from other languages, why not borrow the names (structure or record) of those features? Language is a living thing that doesn’t accept bad terminology without a fight. On the Visual Basic programming team, user-defined types have become known as UDTs. Think of them as Unified Data Templates or whatever seems to fit the acronym. In any case, this book calls them UDTs from here on out.
I borrowed the one-character type prefix from similar conventions in C++. It avoids one of my pet peeves—naming conventions that make it difficult to distinguish between types and variables. Some conventions use a lowercase prefix to indicate different kinds of types and the same prefix for variables of that type. Such a convention might use clsDrive for a drive class or udtPoint for a point type. When the same kind of prefix is used for variables as for types, you might end up with statements like this:
Dim clsAnimal As clsAnimal
But of course that’s illegal, so you end up modifying it like this:
Dim clsAnimalVar As clsAnimal
Another common problem is to not use a naming convention for classes. Instead, give the class the obvious name (Animal). But then you end up with the same problem:
Dim Animal As Animal
You’re using up the best name for the class, but you’d be better off saving it for the variable. This confusion comes from an ambiguity in human language. Nouns indicating a type of thing (animal) are often identical to the noun for a particular object of that type (animal). It’s as if our brains were automatically parsing the following statement:
Dim animal As Animal
That works for humans, and it even works for some case-sensitive computer languages, but it’s not specific enough for Visual Basic. That’s why I prefer a different kind of prefix for types than for variables. You can use more natural statements like this:
Dim animal As CAnimal
Some conventions use a single prefix to represent all variables of a particular type. For example, udt represents all user-defined types and cls represents all classes. The original Hungarian required a separate variable prefix for every type defined by the user—class, form, control, enum, or UDT. I prefer this because prefixes like cls and udt tell me nothing useful about the variables or object variables that use them. Sometimes the variable prefix for new classes just jumps out at me. For instance, drive and drives were the obvious choices for CDrive and CDrives, discussed in Chapter 4. These might be long prefixes, but generally you’ll have only one variable of each type, so it works out. The main point is to choose prefixes you can remember. In some cases, I use the first letter of each uppercase letter of the type to form the prefix. For example, my prefix for the enum ESortType is est.
The latest trend is to apply Hungarian to filenames as well as to variables and types. You end up with filenames like clsAnimal.Cls and frmOpen.Frm. This convention was unintelligible in 16-bit operating systems with uppercase eight-character names. Mixed-case long filenames make it more readable but no less redundant under Microsoft Windows 95 and Microsoft Windows NT. At any rate, you won’t see it in this book. If I have a CAnimal class and an FOpen form, the filenames are ANIMAL.CLS and OPEN.FRM.
The trouble with naming conventions is that you’ll have a hard time sticking to just one. Let’s say that you buy my arguments and adopt my Basic dialect of Hungarian. But you also use a lot of Windows API calls, so you need to be familiar with Windows Hungarian as used in the Windows SDK. In addition, you read a lot of sample code from the Basic manuals, which use a different version of Hungarian. The code you paste from Visual Basic Help usually doesn’t use Hungarian. Visual Basic for Applications is gradually developing its own conventions for dealing with Visual Basic components. And of course you probably have several other third-party books in your Basic library, each with a different convention. Some of them might even use the dreaded Command1 default convention.
And that’s just Basic. If you write the occasional components or DLL in C++, you’ll have to deal with conflicting conventions from Windows, the Microsoft Foundation Class Library (MFC), and the Component Object Model (COM).
Stir It Up
It’s a hard life. All you can do is choose the naming convention that makes the most sense to you and then stick with it, no matter what other folks (me included) might say.