Naming Conventions

We use a simplified form of Hungarian notation, a naming convention that takes its name from the nationality of its creator, Charles Simonyi. Certain elements of Hungarian notation are used in Microsoft's Visual Basic manuals. Microsoft also uses Hungarian notation internally as part of its coding conventions, as do many developers around the world. Our simplified form of this notation is used to attach both type and scope information to various object names. Hungarian notation uses character prefixes to denote type, aggregation, and scope, and the full system gets rather complicated. The subset we've chosen for our purposes is defined in the following sections and in the tables that appear at the end of this appendix.

Type Information

Hungarian type prefixes have two parts: a base type to represent the base data type and a modifier to denote an aggregate type. An example of a base-type prefix is n, which denotes an integer, while adding the a modifier to the base type denotes an array of integers. An example should make this clearer:

 Dim nCounter            As Integer Dim anCounters(1 To 10) As Integer 

Notice that the variable name itself starts with an uppercase letter, which shows us where the prefix stops and the variable name starts. Sometimes we need to use more than one modifier, such as a multidimensional array:

 Dim aanStateTable(1 To 10, 1 To 10) As Integer 

The base types and modifiers we use are listed at the end of this appendix. In fact, we use only one aggregate modifier since arrays are the only single-type aggregates that Visual Basic supports.

Where calls are made to Windows API functions, you might see type prefixes such as LPSTR and sz that don't appear in our tables: these prefixes are used in the Microsoft Windows documentation. We've found that changing these to match our Visual Basic data types can often conceal errors in the declarations. You might also see p used as a modifier to denote a pointer and pcb to denote the address of a callback function.

For variables defined with user-defined types (UDTs) and classes, the special base-type prefixes t and C are used. Although C breaks the lowercase rule, we've adopted it because it's used throughout the industry.

Menus are named with the type prefix mnu, but the names are aggregated to show the menu structure. For example, the Open item on the File menu is called mnuFileOpen. Here are some more standard menu names:

 mnuHelpAbout mnuFileExit 

Scope Information

We also use prefixes to denote an object's scope. Our scope prefixes come between the type prefix and the object name, so we need to make sure they start with an uppercase letter and end with a lowercase letter. This way, the scope prefixes stand out from both the type prefix and the object's name. For example, a private integer variable (scope prefix Pi) defined at the module level would be named like this:

 Private nPiCounter As Integer 

Variables

Variables are named like this:

 <type><scope><name> 

The name part is simply the variable name written in mixed case, and the type part is a Hungarian type as defined earlier. We don't use type and scope prefixes when naming properties and methods of classes and forms.

The base types and modifiers are given in a table at the end of this appendix. The scope part is defined in the following sections.

Local variables

Local variables do not have a scope prefix. Here are some examples of local variable definitions:

 Dim nCounter  As Integer Dim sMessage  As String Dim tThisCell As tTableEntry  ' A user-defined type ReDim anLookupTable (1 To 10) As Integer 

Private variables

Private variables defined at the module level have Pi as a scope prefix. Some examples follow:

 Private nPiCounter  As Integer Private sPiMessage  As String Private tPiThisCell As tTableEntry  ' A user-defined type Private anPiLookupTable () As Integer 

Global variables

Public variables defined at the module level of a standard module (that is, a BAS file) have the module identifier as a scope prefix. The module identifier is a unique two-character prefix that suggests the module name. For example, we might choose Er for an error handling module or Db for a database module. We also use an additional scope prefix, pu, to identify the variable as public. Here are some examples.

 Public nPuErCounter As Integer          ' Er for "error handling" Public sPuErMessage As String Public anPuTbLookupTable () As Integer  ' Tb for "table functions" Public tPuTbThisCell As tTableEntry     ' A user-defined type 

Form and class properties (unprotected)

Public variables defined at the module level of classes and forms are properties and do not have scope or type prefixes.

Functions and Subroutines

Public functions and subroutines have scope prefixes in the same way that variables do. Public and private functions also have a type prefix that reflects the type of value returned. The rules for choosing the type prefix are the same as those for variables.

Private subroutines

Private subroutines and functions do not require scope prefixes. Here are some examples of private subroutines:

 Private Sub OpenLogFile() Private Sub ClearGrid() 

And here are some private functions:

 Private Function nGetNextItem() As Integer Private Function sGetFullPath(ByVal sFileName As String) _ As String Private Function CGetNextCell() As CTableEntry 

Public subroutines

The rules for choosing scope prefixes for public subroutines are exactly the same as those for variables, as shown here:

 Public ErReportError() Public TbInsertTableEntry() Public DbDeleteItem() 

Form and class methods

Public functions and subroutines defined in classes and forms are properties and do not have type or scope prefixes.

Form and class properties (protected)

Property Let, Property Set, and Property Get routines do not have type or scope prefixes.

DLL procedures

When declaring Windows API functions, we use the Alias keyword to add the prefix Win. For example, CallWindowProc becomes WinCallWindowProc. When declaring functions in other DLLs, we use the prefix Dll.

Parameter lists

Formal parameters are named as local variables but with i or o added in place of a scope prefix to denote whether the parameter is an input or an output:

 Sub CrackURL(ByVal siURL As String, ByRef soProtcol, _     ByRef soPath, ByRef soPath, ByRef noPort) 

For parameters that are both inputs and outputs, we use io.

Controls and Forms

We also use type prefixes when naming Visual Basic controls. The prefixes are given at the end of this appendix. Forms are named as if they were controls, even though a form name can also act as a class name. For example, we would name a form frmPublication instead of CPublication, even though we could create new instances of the form:

 Dim frmNewPub As New frmPublication 

Constants

Constants are named in uppercase letters, with no type or scope prefixes. Arbitrary prefixes can be used to group sets of related constants:

 Const TABLE_SIZE            As Integer = 100 Const DEFAULT_LOG_FILE      As String = "log.txt" Const ERR_GENERIC           As Integer = 32767 Const ERR_LOGON_FAIL        As Integer = 32766 Const ERR_COMPONENT_MISSING As Integer = 32765 

Type and Class Definitions

Type names are prefixed with t, and class names are prefixed with C. These prefixes are also used as the base-type prefixes when naming instances. The rest of the name is written in mixed case:

 Type tTableEntry     nNewState As Integer     lAction   As Long End Type 

And in use:

 Dim tCell         As tTableEntry Dim CSymbolTable  As New CTable 

Source Files

Source filenames are restricted to the traditional 8.3 format. The first three characters are reserved for a project identifier, and the default file extensions are retained. The remaining five characters are used to distinguish files in whatever way seems appropriate.

OtherNaming Conventions

This is an example of a local string:

 Dim sCustomerName As String 

This is an example of a module-level integer:

 Dim nmCustomerId As Integer 

Here is a global-level Double defined in the module Mi:

 Public dPuMiCustomerNumber As Double 

Here is a global-level Double; the module identifier is not defined or else resident in the project-wide globals module.

 Public dPuCustomerNumber As Double 

This is a global array of Longs. The module identifier is not defined or else resident in the project-wide globals module.

 Public alPuAmounts(1 to 25) As Long 

This is a global database. The module identifier is Dt:

 Public dbPuDtCustomers As Database 

This shows a call to an external DLL function; the result is assigned to a global variable resident in the project-wide global's module.

 bPuRetCode = bDllIsShareLoaded ()