NAMING CONVENTIONS FOR VBA OBJECTS

Tags are required for the following VBA objects:

• Variables

• Type structures

• Constants

Optional tags also are available for some types of procedures. By definition, if you're a Level One user, LNC assumes that you aren't writing Visual Basic code. If you're creating procedures, you're a Level Two user and should always apply Level Two tags and prefixes to database objects as well as VBA objects.

Base names are optional in some Level Two constructions. When you're programming in VBA in Level Two, the tag element is always required, but the BaseName is optional for local variables only. For example, a procedure that declared only one form object variable can legitimately use the variable name frm, which is a tag without a base name. Type structures, constants, and variables that have module-level or public scope must have both a tag and base name.

Tags for Variables

Visual Basic variable tags are noted in Tables D.11 through D.14, grouped by type of variable. In Tables D.11 and D.12, tags for collection variables are made by adding s after the tag for the object type stored in the collection.

Public Enum penmMenuLoca  ' Location of new menu items
  penmMenuLoca_Top = 0     ' At the top of menus
  penmMenuLoca_Bottom = 1  ' At the bottom of menus
End Enum

Even though I noted earlier that a tag by itself is a legitimate variable name, the variable tag int is a reserved word and won't compile in VBA by itself—it requires a base name.

Information on creating variables for Automation coding can be found in the “Leszynski Naming Conventions for Microsoft Solution Developers” product (see the end of this appendix for more information).

Prefixes for Variables

You can categorize the prefixes for Visual Basic variables into two groups: prefixes for scope and all other prefixes. Because the model for variable scope changed somewhat in Access 95, let's discuss scope prefixes first. The following prefixes are ordered by increasing (broader) scope:

• No prefix Use no prefix for variables that are local to a procedure.

• s Place this prefix before locally declared variables in a procedure with a Static statement.

• m Use this prefix for module-level variables declared with Dim or Private statements in the Declarations section of a module.

• p Use this prefix to denote variables declared as Public in the Declarations section of a form or report module. Such variables are publicly available to other procedures in the same database only.

• g Use this prefix to denote variables declared as Public in the Declarations section of a standard module. Such variables are truly global and may be referenced from procedures in the current database or other databases.

When used, scope prefixes always begin a variable name and precede any other prefixes.

In addition to scope, prefixes can identify the following other characteristics of variables:

• a Use this prefix to denote a variable that's declared as an array, including a ParamArray argument in a function.

• c This prefix is placed before constants defined by the user.

• e Use this prefix for a variable that's an element of a collection. Such variables are usually part of a For Each...Next loop structure.

• i Use this prefix to denote a variable (usually of type Integer) that serves as an index into an array or an index counter in a For...Next loop.

• o This prefix is placed before object variables that reference Automation servers through late binding (an object variable), where the tag denotes the type of server.

• r Use this prefix for variables that are arguments (parameters) passed into a procedure and declared as ByRef, or not declared as either ByRef or ByVal (including a ParamArray), which implies ByRef.

• t Use this prefix to describe a variable that's declared as a user-defined type structure. The variable should inherit the base name from the original declaration for the type.

• v Use this prefix for variables that are arguments (parameters) passed into a procedure and declared as ByVal.

Because a prefix provides a very detailed description of a variable, the number of allowable prefix combinations is limited, as shown in Table D.15.

Variables require a unique prefix when declared Public in a widely distributed application. See the later section “Tags and Prefixes for Procedures” for more information.

Naming Constants

Access 95 introduced sweeping changes in the area of constants. The changes most relevant to naming conventions include the following:

• A constant can now be assigned a data type when it's defined.

• All constants have been renamed and carry a tag of ac, db, or vb to identify their primary functional area.

• Constants can now be created with the Variant data type.

When creating constants, use a scope prefix (if appropriate), the prefix c, and the suitable tag for the constant's data type. To properly synchronize the tag and the data type, don't let Access assign the type; always use the full Const name As datatype syntax.

Constants require a unique prefix when declared Public in a widely distributed application to prevent name contention. See the following section for more information.

Tags and Prefixes for Procedures

Whether and how to prefix and tag procedure names is a debatable subject. In general, this style neither requires nor encourages placing characters before a procedure name, except in the following situations.

Prefixes for Procedures

Procedures can have scope similar to that of variables—s (static), m (private), p (public), or g (global public). LNC supports the use of these scope prefixes on function names if they solve a particular need and are used consistently throughout an application.

If you're creating software (applications, wizards, ActiveX servers, and so forth) for retail, for inclusion in the public domain, or for broad distribution in some other manner, LNC requires that you prefix Public variables, constants, and procedures with a unique author prefix identifying you or your company. The prefix consists of two or three unique characters and an underscore, and prevents your object names from conflicting with object names in other referenced or referencing databases on a user's machine.

To create an author prefix, use your personal or company initials. For example, author prefixes for my companies are lci_ for Leszynski Company Inc. and kwc_ for Kwery Corporation. Before using your selected prefix, make an effort to determine whether the prefix is already widely in use.

Tags for Procedures

The LNC style prescribes the following naming convention tags for procedures:

• api Use this tag for declare statements for function calls to the Windows API.

• cbk This tag indicates a procedure in a form module that is structured as a list callback function.

• cbf Use this tag on procedure names for code behind a form or report. This tag clearly differentiates such procedures from Property and event procedures.

• mtd Use this tag on custom method procedures defined for class modules.

• prp Use this tag on Property procedure names defined with Property Get, Property Let, and Property Set statements. This tag clearly differentiates such procedures from functions, subprocedures, and event procedures.

LNC doesn't require or suggest assigning a data type tag to functions to reflect their return value. However, if you have a specific need to tag procedures to reflect their return value type, use the appropriate tags from the earlier section “Tags for Variables” and apply them consistently to all procedures in an application.

Using Macros Instead of VBA

Occasionally, you might have a good reason for using macros to create action scripts. If so, apply the rules described in the preceding section for VBA procedure base names to your macro base names. Macro groups in the Database window should use the macro prefixes and tags noted earlier. Individual macros within a macro group don't have prefixes or tags, except for event macros.

All macros for a specific form or report should be placed into one macro group, with the form or report name as the macro base name. Within the macro group, create standard macros and event macros for the form or report. If a macro is tied to a form or report event, show the event name or an abbreviation in the macro name. For example, you would store macros related to frmCust in macro group mfrmCust. Event macro names in the group might include Form_Current and txtLastName_Change.

Macros that aren't specific to a form or report should hold actions that have some common functionality or purpose. Use the same grouping methodology (related items together) that you would apply to locate procedures in VBA modules.

Visual Basic Object Name Examples

Table D.16 shows examples of Visual Basic variables applying the various conventions discussed so far.

Function lci_ArraySum (ParamArray
ravarNum() As Variant) As Double

Function FileLock(ByVal vstrFile
As String) As Integer