Donald Firesmith Document ID: VBCS Version: 0.

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

Visual Basic Coding Standards (VBCS)

Version 0.1
(Draft)

Public Domain  1999 by Donald Firesmith Page 1

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

Revision History
Date Issue Description Author
11/03/99 0.1 Initial draft Steve Schmitt

Public Domain  1999 by Donald Firesmith Page 2

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

Table of Contents
1 OBJECTIVES.....................................................................................................................................................5

2 WHY HAVE CODING CONVENTIONS........................................................................................................5

3 DEFINITIONS....................................................................................................................................................5

4 USAGE GUIDELINES.......................................................................................................................................6
4.1 OPTION STATEMENTS..........................................................................................................................................6
4.2 DECLARATIONS..................................................................................................................................................6
4.3 ERROR HANDLING..............................................................................................................................................7
4.4 TESTING...........................................................................................................................................................8

5 SOURCE CODE FORMATTING.....................................................................................................................8

5.1 CODE ORGANIZATION.........................................................................................................................................8
5.2 INDENTATION.....................................................................................................................................................9
5.3 SPACES.............................................................................................................................................................9
5.4 MAXIMUM LINE LENGTH..................................................................................................................................10
5.5 BLANK LINES..................................................................................................................................................10

6 COMMENTS.....................................................................................................................................................11
6.1 COMMENT FORMATTING....................................................................................................................................11
6.2 MODULE COMMENTS........................................................................................................................................11
6.3 PROCEDURE COMMENTS....................................................................................................................................11
6.4 DECLARATION COMMENTS.................................................................................................................................12
6.5 GENERAL COMMENTS.......................................................................................................................................12

7 NAMING CONVENTIONS.............................................................................................................................13
7.1 MODULE NAMES.............................................................................................................................................13
7.2 PROCEDURE NAMES.........................................................................................................................................13
7.2.1 General Procedure Names...................................................................................................................13
7.2.2 Boolean Function Names....................................................................................................................13
7.2.3 Conversion Method Names..................................................................................................................14
7.2.4 State Modifying Method Names...........................................................................................................14
7.3 VARIABLE AND PARAMETER NAMES...................................................................................................................14
7.3.1 Atomic Types........................................................................................................................................14
7.3.2 Object and Complex Types..................................................................................................................14
7.3.3 Constant Names...................................................................................................................................15
7.4 ARRAY NAMES................................................................................................................................................16
7.5 GLOBAL VARIABLE NAMES...............................................................................................................................16
7.6 MISCELLANEOUS..............................................................................................................................................16

Public Domain  1999 by Donald Firesmith Page 3

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

8 AVOIDING COMMON ERRORS..................................................................................................................17

Public Domain  1999 by Donald Firesmith Page 4

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

1 Objectives
The objectives of this standard are:
• To document the Visual Basic coding conventions.
• To improve the quality of the deliverable software and its associated documentation.
• To improve communication within the development and maintenance teams.
• To decrease the costs associated with the software and its associated documentation.

2 Why have Coding Conventions

Visual Basic design and coding conventions are important for a number of reasons:
• Software is read many more times than it is written, often by someone other than its developer.
• Coding conventions increase the readability of the software, permitting software engineers to
understand and maintain software more quickly and correctly.
• From 70% to 90% of the cost of software is in maintenance rather than development.
• The original developer will rarely maintain any software for its entire life.
• Software is a critical part of our products; it should be just as well engineered, packaged, and
documented as our hardware.
• Providing standard coding conventions permits the developer to concentrate on more important
issues such as design.

3 Definitions
A convention is one of the following:
• A standard (S) is a mandatory constraint on the content or format of something (e.g., code,
documentation). You must follow standards unless you obtain a waiver from the Process Team
and you document the deviation from the standard.1
• A guideline (G) is an optional constraint on the content or format of something (e.g., code,
documentation). You should follow guidelines in most cases. You must document any deviation
from the guideline.
• A recommendation (R) offers advice. It is less constraining than either a standard or guideline.
You may follow or ignore recommendations as appropriate. You need not document any
deviations from recommendations.
Visual Basic (VB for short) refers to any programming environment, which uses a Visual Basic-like
language. The standards in this document apply to these other environments, as well as Visual Basic
itself:
• Visual Basic for Applications (VBA), used in Microsoft Office products
• Visual Basic Script (VBScript), used in Active Server Pages and in MS Outlook

1
You do not need to document or obtain a waiver to use an exception that is included in this
document.
Public Domain  1999 by Donald Firesmith Page 5
 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

• LotusScript, used in Lotus Notes.

A module is a block of code (declarations and procedures) which VB stores in a single file. Forms,
Classes, UserDocuments, and Code Modules will all be referred to as modules in this document. In
LotusScript, each object (Agent, View, Form) may be considered a module. In VBScript, each file
may be considered a module.
Procedure refers to a Sub, Function, or Property Let, Get, or Set function.

4 Usage Guidelines
The following sections provide standards and guidelines for the general usage of Visual Basic. These
standards ensure consistent usage of various Visual Basic features.

4.1 Option Statements

S) Use Option Explicit. Option Explicit should be included at the beginning of each module to
enforce explicit declarations for all variables. In the VB environment, the option to “Require
Variable Declaration” should be set. This tells VB to include Option Explicit in all new modules.
Rationale: When variables can be instantiated on the fly, typographical errors in variable names
are not caught by the compiler and can cause run-time errors.
S) Do not use Option Base. The default lower bound of 0 (zero) should be used for arrays; do not
use Option Base to change it. If a different lower bound is needed for an array, explicitly define
both the lower and upper bound of the array in the Dim or ReDim statement.
Rationale: Most programmers will assume that the lower bound of arrays is 0. A change in the
lower bound will not be apparent to someone in the middle of reading the code. But this will not
be apparent to someone
Example:
‘* Array from 0 to 10, using default lower bound.
Dim aWords(10) as String
‘* Array from 1 to 12, both bounds explicit.
Dim aMonths(1..12) as String

4.2 Declarations
The following conventions help you build good abstractions that maximize cohesion:
S) Use narrow scoping. Use private variables and constants whenever feasible. Local (procedure-
level) variables are preferred, followed by module-level, with globals as a last resort.
Rationale: Increases cohesion.
S) Declare module level variables in this order:
1. Public API Declarations
2. Public Constants
3. Public Types
4. Public Variables

Public Domain  1999 by Donald Firesmith Page 6

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

5. Private API Declarations

6. Private Constants
7. Private Types
8. Private Variables
Rationale: A consistent declaration order makes the module header easier to scan. The
prescribed order provides clear separation between Public and Private declarations, and suggests
an appropriate dependency between Constants, Types, and Variables.
S) Declare scope explicitly. Use Private and Public, instead of Dim, for variables declared outside
of procedures.
Rationale: VB has different defaults for each type of code module (form, class, etc.). Explicitly
declaring the scope of variables reduces confusion.
R) Declare variables and constants at the beginning of their applicable scoping construct (module or
procedure). VB allows you to declare variables anywhere within a module or procedure, but they
should be placed at the top.
Rationale: This makes declarations easy to view, and avoids cluttering up the flow of executable
code. Usually the rationale for putting the declarations in the middle of the executable code is
that it declares variables near the point where they are used. But this is only important if
procedures are allowed to grow beyond a managable size. If a block of code is independent
enough to require its own variables, it belongs in a separate procedure.
S) Use explicit types. Each variable should be declared with an explicit type, to prevent VB from
creating all variables in the Variant type. If Variants are needed, they should be declared
explicitly As Variant.
Rationale: Variants should be avoided because they are less efficient than defined types, and
because their use prevents VB from catching errors through type-checking.
Exceptions: The VBScript environment only supports Variant types, and does not allow you to
declare a variable as an explicit type. In VBScript, comments and naming conventions should be
used to inform the reader as to the intended use of the variable.
T) Use narrow typing for objects. Don’t use an Object type when the true type of the object is
known. For example, if a variable contains a reference to a TextBox, the variable should be
declared As TextBox, not As Object or As Control
Rationale: Narrow typing makes the true purpose of the variable more obvious. It also allows
VB to catch type mismatch errors at compile time, and execute more quickly at run time through
early binding.

4.3 Error Handling

The following conventions help you to handle errors effectively:
R) Include error handling in every event procedure. Each event procedure should have an On
Error statement as its first executable statement.
Rationale: In VB, unhandled errors result in termination of the program. Since all code is
executed as the result of an event, event procedures represent the last chance to handle errors,
which bubble up from other procedures.
Public Domain  1999 by Donald Firesmith Page 7
 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

R) Include error handling in every procedure where errors are likely to occur. This includes any
procedure that performs I/O, database functions, operating system calls, COM operations, or
invokes methods on other objects. Errors should be handled in the same procedure where they
occur.
Rationale: Localized error handling increases cohesion, and allows you to provide error handling
specific to the types of errors that are likely to occur. The farther that a project-specific error
bubbles up, the less likely that it will make sense to the procedure that must handle it.
R) Use common error trapping label names. Use the same label name (for example, “ErrTrap”) in
all procedures
Rationale: This improves the consistency and readability of the code.
Example:
Sub cmdOK_Click
On Error Goto ErrTrap

‘* … More code here …

Exit Sub

ErrTrap:
MsgBox “Error “ & Err.Number & “: “ & Err.Description & “
in “ & Err.Source, vbExclamation, App.Title

End Sub

4.4 Testing
R) Use Debug.Print Statements. Print the value of variables to help confirm intermediate results
and confirm that code is executing as expected. Debug.Print statements are ignored when the
code is compiled
Rationale: Makes code verification and debugging easier.

5 Source Code Formatting

The following standards provide a consistent look and feel to the Visual Basic code and improve its
design.

5.1 Code Organization

The following conventions will help to ensure that the code is organized into easy-to-understand
pieces.
R) Keep modules to a manageable size. Each module should be less than about 1000 lines, and
contain a set of procedures that are related to each other. If a module is becoming larger than
1000 lines, consider splitting it based on some functional criteria.

Public Domain  1999 by Donald Firesmith Page 8

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

Rationale: Small, cohesive modules are more manageable and easier to understand. They also
reduce sharing conflicts in version control tools.
R) Avoid putting general code in Form modules. Form modules (and other modules with a visual
interface) should contain only the event procedures for the form. Procedures called by the event
procedures should be placed in other modules unless they deal directly with many of the controls
on the form itself.
Rationale: Form modules tend to grow large through their event procedures and visual
interface definitions. Moving other code into other modules will help to keep Form modules
small and focused on their main purpose, which is interacting with the user.
Because Forms consist of both binary and textual components, they are not handled as well
by version control tools. Keeping code in other modules minimizes conflicts.
R) Keep procedures to a manageable size. Each procedure should be concise enough that its entire
purpose can be easily expressed and understood. One rule of thumb is that the well-commented
procedure should fit on a printed page. A more relevant rule when editing the code is that it fit on
one screen in the development environment.
Rationale: Small procedures are easier to understand and verify.
Exception: A single control structure (for example, a Select structure) may be unavoidably longer
than the recommended procedure length. In this case, the control structure should be placed in its
own procedure, separate from other code, so as not to obscure the function of the code around it.

5.2 Indentation
G) Use the standard indentation provided by Visual Basic tabs. The VB environment provides tools
that make it easy to indent blocks of code by tab stops.
Rationale: Indentation improves readability. Using the standard tab-stop indentation improves
maintainability, allowing the indent level of blocks of code to be easily changed.
Exception: LotusScript indents automatically, and does not support tabs.
G) Use four spaces for each indent level. The default tab spacing of in VB is four spaces, and this
should be maintained.
Rationale: Four spaces is enough to make the indentation level obvious, without taking up too
much horizontal space.
Exception: LotusScript indents automatically

5.3 Spaces
R) Apply spaces liberally.
Rationale: Spaces break up the code, making it easier to read.
Example 1:

Public Domain  1999 by Donald Firesmith Page 9

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

void someMethod (TypeX aTypeX, TypeY aTypeY) throws

SomeException;

5.4 Maximum Line Length

G) Avoid lines longer than 80 characters.
Rationale: Longer lines are more difficult to read. Also, many terminals and tools do not handle
longer lines well.
G) Break up long procedure declarations on to multiple lines with each parameter aligned.
Rationale: This makes the code much easier to read and makes it less likely that maintenance
will introduce new bugs.
Example:
Function CollectStats(sFileName As String, _
iStartLine As Long, _
iEndLine As Long) _
As Long

G) Limit method and object reference cascades to three levels.

Rationale: Method cascades can be hard to understand and can be the source of synchronization
and exception handling problems. It slower to execute statements using multiple cascades.
Visual Basic must traverse the object hierarchy from the top for each statement, so it is more
efficient to assign a variable to a lower-level object if it will be used for multiple statements.
Acceptable Examples:
returnValue = anObject.method1().method2()
returnValue = anObject.method1().method2().method3()
oSelection = Word.ActiveDocument.Selection
iStart = oSelection.Start
Not Acceptable Example:
returnValue = anObject.method1().method2().method3().method4()
Word.ActiveDocument.Selection.Font.Bold = True

5.5 Blank Lines

S) Put a blank line between logical sections of a procedure.
Rationale: This improves readability.
Example:
Sub ProcessData()

Public Domain  1999 by Donald Firesmith Page 10

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

CheckPrecondition

DoFoo
DoFam

CheckPostcondition
End Sub
Comment: If the method is long or violates other standards, it should be factored based on the
logical sections described above.

6 Comments
The following Visual Basic comment standards provide a consistent approach to documenting code
that will also improve the quality of the associated javadoc documentation.

6.1 Comment Formatting

R) Begin comments with ‘* (an apostrophe, an asterisk, and a space). All VB comments start with
an apostrophe and end with a line break. This convention adds an asterisk and space before the
actual comment text.
Rationale: When viewing VB code, the apostrophe alone does distinguish the comment well
from the code. The asterisk and space improves legibility by setting the comments off more
clearly.

6.2 Module Comments

S) Write a comment block at the top of each module. The comment block will include the name of
the module, a description its purpose, its authors, and its revision history. It should also contain
version and copyright information, if appropriate. Each entry in the revision history will include
the date that the change was made, the author who made the change, the reason that the change
was made, and a list of the procedures affected.
Rationale: Module-level comments help future programmers to understand and respect the
purpose of the module, and to consider the potential impacts before making revisions.

6.3 Procedure Comments

S) Begin each procedure with a comment block. The comment block shall immediately follow the
declaration of the procedure, and contain a description of the procedure, including the reason why
it is needed. Following that should be a list of the pre- and postconditions necessary for its
operation, a description of its parameters and return value, and possible errors which may occur.
Rationale: Well-commented procedures make the code easier to understand.
Example:
Function CheckSpelling(txtComments As VBA.TextBox) As Boolean

Public Domain  1999 by Donald Firesmith Page 11

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

‘* Run the spell checker on the textbox. This prevents

‘* spelling errors from being stored and displayed to the
‘* customers.
‘* Preconditions: Textbox has been filled
‘* Postconditions: The data in the textbox may change if
‘* spelling corrections have occurred
‘* Parameters:
‘* txtComments – TextBox containing free-form text
‘* Return Value:
‘* Boolean indicating whether spelling errors were found.

6.4 Declaration Comments

G) Describe the abstraction of all declared constants, types, and variables, the meanings of which are
not obvious from the name. This includes both module- and procedure-level declarations. Also,
describe any constraints of the variables.
Rationale: This will make the code easier to understand and maintain.
Example:
Dim iPrevPos As Long ‘* Previous cursor position
‘* (0..MAXPOS)

6.5 General Comments

G) Do not comment obvious code. If the code is not obvious, then first see if you can rewrite the
code so that the use of comments will be unnecessary.
Rationale: This will make the code easier to maintain.
Bad Example:
Dim iConnectionCount As Long ‘* number of connections
G) Where practical, line up trailing comments.
Rationale: This will make the comments easier to see, compare, and maintain.
Example:
If Not DataReady() Then ‘* precondition fails
Error 30005, “Data not available”
Else ‘* normal case
ProcessData
End If
S) Use proper spelling, punctuation, and spelling in comments.
Rationale: Poorly written comments are distracting and can obscure the intended meaning.
Public Domain  1999 by Donald Firesmith Page 12
 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

7 Naming Conventions
Naming conventions are partly based on those found in Bruce McKinney’s Hardcore Visual Basic.

7.1 Module Names

S) Module names should be meaningful words or phrases that describe the abstraction of the
module. Use nouns for object abstractions and verbs for functional abstractions. Module names
should be without spaces, in mixed case, with the first letter uppercase, and the first letter of each
subsequent word capitalized. The file name of the module should match the internal name of the
module
Rationale: Consistency with standard Visual Basic naming conventions. Ease of deployment.
Examples:
ShowMatches.frm
Registry.bas
SendMsg.bas
Customer.cls

7.2 Procedure Names

7.2.1 General Procedure Names

S) Procedure names should be meaningful verbs or verb phrases that describe the functional
abstraction of the procedure. The first word should be a verb. Procedure names should be without
spaces, in mixed case, with the first letter uppercase, and the first letter of each subsequent word
capitalized.
Rationale: Consistency with standard Visual Basic naming conventions. Encourages names
which allow the reader to visualize the purpose of the procedure
Example: OpenDataFile

7.2.2 Boolean Function Names

S) Functions that return the results of a test of a Boolean condition T should be named IsT,
HasT, or CanT.
Rationale: Consistency with standard Visual Basic naming conventions. Encourages readable
code when the function is used in a condition.
Examples:
Connection.IsAvailable()
Router.HasPendingRequest()
If IsBroken() Then Exit Sub

Public Domain  1999 by Donald Firesmith Page 13

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

7.2.3 Conversion Method Names

S) Name methods that convert an object to a particular format F ToF.
Rationale: Consistency with standard Visual Basic naming conventions.
Example: toString

7.2.4 State Modifying Method Names

S) Name methods that modify the state of an object to state S BeS.
Rationale: Consistent naming.
Examples:
BeAvailable()
BeUnavailable()

7.3 Variable and Parameter Names

Variable and parameter names should be meaningful noun or noun phrases, without spaces, with the
first letter lowercase and the first letter of any subsequent words capitalized. The first few letters of
the variable name define the type of the variable. The remainder of the name should describes the
role that the variable plays.

7.3.1 Atomic Types

S) For atomic types, the first letter of the name defines the type, as follows:
Prefix Type Example
i Integer or Long iWordCount

f Float (Single or Double) fRadius

s String sFirstName

b Boolean bQuiet

c Currency cCurrentBal

d Date dStartTime

Rationale: Consistency with standard Visual Basic and Windows API naming conventions.
Allows easy identification of the type and role of a variable, without adding a lot of naming
overhead for frequently used types.

7.3.2 Object and Complex Types

S) For objects and complex types, and three-letter prefix defines the type, as follows:
Prefix Type Example

Public Domain  1999 by Donald Firesmith Page 14

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

frm Form frmCustInput

txt TextBox txtLastName

lst ListBox lstServiceTypes

cmd Command Button cmdCancel

cbo ComboBox cboCategory

pic PictureBox picLogo

chk CheckBox chkPrimaryAddress

opt Option Button optGenderFemale

tmr Timer tmrElapsed

lbl Label lblCopyright

tbr Toolbar tbrEditing

ctl Control (if type is not known) ctlSortableList

col Collection colFormFields

obj Object (if type is not known) objParent

var Variant (if type is not known) varNextField

Many other types are possible which are not on this list, including user-defined types and objects.
For these types, and appropriate three- or four-letter prefix convention should be established and
documented for the project.
(Note that the frm prefix should be used only for a variable in the code which holds a form
reference, and not the VB class and file which defines the form. Form modules should be named
as per the section “Module Names”, above.)
Rationale: Consistency with standard Visual Basic and Windows API naming conventions.
Allows easy identification of the type and role of a variable.

7.3.3 Constant Names

S) The names of constants should be meaningful noun or noun phrases with all letters capitalized
and underscores between words.
Rationale: Consistency with standard Visual Basic and Windows API naming conventions. This
convention emphasizes and differentiates constants from variables.
Example: MAXIMUM_NUMBER_OF_FILES

Public Domain  1999 by Donald Firesmith Page 15

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

7.4 Array Names

S) Array names should begin with a lower case “a”, followed by the prefix which describes the type
of the array members, as described above, and followed finally be the descriptive name of the
variable.
Note that Variants must often be used to hold arrays when they are passed as return values from
functions. In this case, the Variant should be named according to the array naming convention.
Rationale: This identifies the variable as an array, and indicates its contents as well.
Example:
Dim asUserNames(10) As String
Dim afVertices() As Single
Dim asWords As Variant
asWords = Split(sLine, vbTab)

7.5 Global Variable Names

S) Names for global variables should follow the above conventions, but with a “g_” prefix before
the name. Likewise, private module-level variables should have a “m_” before the name.
Rationale: This eases identification of global and module-level variables. While this convention
is somewhat cumbersome, it appropriately discourages use of global and module-level variables.
Example:
Public g_sCurrentUser As String
Private m_aiTroubleCodes As Integer

7.6 Miscellaneous
S) Do not use abbreviations or acronyms unless they are extremely popular abbreviations in the
project. The prefix standards described above or established by the project are examples of
popular abbreviations, which are exempted.
Rationale: Abbreviations and acronyms make the code harder to understand.
Example:
sOutstandingBalance instead of sCurOutBal
S) Document cases where the client ignores the return value.
Rationale: This is typically an error; if not, make the intent clear.
S) Use plural for collections and singular for individual objects.
Rationale: This makes the names easier to understand.
Examples:

Public Domain  1999 by Donald Firesmith Page 16

 Donald Firesmith Document ID: VBCS Version: 0.1

Visual Basic Coding Standards (VBCS) Version Date: 12/28/2000

Dim colOpenForms As Collection

Dim asApprovedNames() As String

8 Avoiding Common Errors

Public Domain  1999 by Donald Firesmith Page 17