• Naming conventions for objects, variables, and procedures
• Commenting conventions
• Text formatting and indenting guidelines

The main reason for using coding conventions is so that you and others can easily read and understand the code. Many companies strictly enforce their coding conventions, making them closer to law than to suggestions.

A good set of coding conventions can help produce precise, readable, and unambiguous source code that is consistent with other language conventions and as intuitive as possible. For example, if we where to use a variable to hold the first name of a customer, which would be more intuitive:

    Dim CFN
    Dim strCustomerFirstName

Without a doubt strCustomerFirstName would be much more intuitive than CFN.

Constant Naming Conventions
Constant names should be uppercase with underscores (_) between words. For example:

APPLICATION_NAME
HELP_FILE

Variable Naming Conventions

For purposes of readability and consistency, use the prefixes listed in the following table, along with descriptive names for variables in your VBCE code.

Subtype	Prefix	Example
Boolean	bln	blnFileExists
Byte	byt	byBitmapData
Date (Time)	dtm	dtmOpening
Double	dbl	dblCalculatedResult
Error	err	errLastErrNum
Integer	int	intCount
Long	lng	lngTotalCount
Object	obj	objOkButton
Single	sng	sngAverage
String	str	strApptName

Variable Scope
Variables should always be defined with the smallest scope possible. VBCE variables can have the following scope.

Scope	Where Variable Is Declared	Visibility
Procedure-level	Event, Function, or Sub procedure	Visible in the procedure in which it is declared.
Application-level	Declarations section of a *.BAS module	Visible in every procedure in the application.

Descriptive Variable and Procedure Names
A variable or procedure name should use mixed case and should be as complete as necessary to describe its purpose. Also, procedure names should begin with a verb, such as GetPathName or DoFinalCalculation. For frequently used or long terms, standard abbreviations are recommended to help keep name length reasonable.

When using abbreviations, make sure they are consistent throughout the entire application. For example, randomly switching between Cnt and Count within an application may lead to confusion.

Object Naming Conventions
The following table lists recommended conventions for the various objects you may encounter while programming in VBCE.

Object type	Prefix	Example
Check box	chk	chkReadOnly
Combo box, drop-down list box	cbo	cboEnglish
Command button	cmd	cmdExit
Common dialog	dlg	dlgFileOpen
Frame	fra	fraLanguage
Horizontal scroll bar	hsb	hsbVolume
Image	img	imgIcon
Label	lbl	lblHelpMessage
Line	lin	linVertical
List Box	lst	lstPolicyCodes
Text box	txt	txtLastName
Vertical scroll bar	vsb	vsbRate
PictureBox	pic	picStartButton

Code Commenting Conventions
All procedures should begin with a brief comment describing what they do. This description should not describe the implementation details (how it does it) because these often change over time, resulting in unnecessary comment maintenance work, or worse yet, erroneous comments. The code itself and any necessary inline comments describe the implementation.

Arguments passed to a procedure should be described when their purpose is not obvious and when the procedure expects the arguments to be in a specific range. Function return values and other variables that are changed by the procedure, especially through reference arguments, should also be described at the beginning of each procedure.

Procedure header comments should include the following section headings.

Section Heading	Comment Contents
Purpose	What the procedure does (not how).
Assumptions	List of any external variable, control, or other element whose state affects this procedure.
Effects	List of the procedure's effect on each external variable, control, or other element.
Inputs	Explanation of each argument that isn't obvious. Each argument should be on a separate line with inline comments.
Return Values	Explanation of the value returned.

Remember the following points:

• Every important variable declaration should include an inline comment describing the use of the variable being declared.
• Variables, controls, and procedures should be named clearly enough that inline comments are only needed for complex implementation details.
• At the beginning of your script, you should include an overview that describes the script, enumerating objects, procedures, algorithms, dialog boxes, and other system dependencies. Sometimes a piece of pseudocode describing the algorithm can be helpful.

Formatting Your Code
Screen space should be conserved as much as possible, while still allowing code formatting to reflect logic structure and nesting. Here are a few pointers:

• Standard nested blocks should be indented four spaces.
• The overview comments of a procedure should be indented one space.
• The highest level statements that follow the overview comments should be indented four spaces, with each nested block indented an additional four spaces.

mike@vbce.com