by Dan Haught
Vice President of Product Development
September 11, 1997
1.The code works (no bugs)
2.The code is documented
3.The code is maintainable
4.The code runs quickly
Unfortunately, meeting these goals is often time-consuming and difficult. To help with this
process, we at FMS have compiled a list of things that we use on a daily basis\u2014tips and
techniques that make it easier for us (and you) to write code that comes closer the lofty goal
of defect-free maintainable code.
Coding style and practices are a heated topic among developers, approaching an almost
religious fervor. The contents of this article should not be construed as the final word\u2014rather,
it is a exposition of the standards we at FMS have found useful in the job of writing code.
There are guidelines contained here that you may not agree with, which is fine; don't follow
them. However, it is important to understand the concepts involved, so let\u2019s dive right in.
This is not a tip, rather it is arequirement for writing VBA code. If you do not use the Option
Explicit statement at the top of every module in your project, you are asking for trouble when
you debug your application. By specifying Option Explicit, you tell VBA to force you to declare
every variable used. This makes it easy to avoid program errors because of misspelled
variable names. For example, the following procedure is in a module that doesn\u2019t have the
Option Explicit statement. Can you find the bug?
Sub ShowBugs ()
Dim intX As Integer
Dim intY As Integer
Dim intZ As Integer
intX = 1
imtY = 2 ' Whoops! Here's a typo\u2026
intZ = 3
When you run this code, you would expect it to assign the values of 1, 2, and 3 to the intX,
intY, and intZ variables, and then print the sum of the three which should be 6. However, this
procedure prints the value of 4 because of a spelling error. Instead of setting intY to 2, the
code is actually setting imtY (with an "m") to 2. Because Option Explicit is not declared, the
first reference to the variable named imtY declares the variable automatically. This means
that this code compiles just fine and doesn\u2019t become a problem until it is actually tested. On
the other hand, if Option Explicit is specified, the above code would generate a compile error,
making it easy to track down the error before you go any further in your development efforts.
Finally, consider this: if the bug in the example were simple to spot, what happens when you
have the same bug buried in hundreds of lines of code? Using Option Explicit is the single
most important thing you can do to write better VBA code.
There are several guidelines to keep in mind when you declare your variables with the Dim
statement. First, organize your Dim statements to keep them all together within a procedure,
or with the declarations section of a module. By placing all Dim statements at the top of a
procedure, you can get a quickinventory of variables that belong to a procedure. You an also
perform quality-control on your variables by visually scanning the entire list at once\u2014you
don\u2019t have to hunt and peck through the entire module.
A quick glance at the code may lead you to believe that three integer variables are being
defined. However, a closer look reveals that intY is not being declared as an integer (it\u2019s
actually a variant.) If each of these variables were declared on a separate line, it would be
quickly apparent that intY was not type cast. By applying this rule to your code, you also
avoid the simple Dim syndrome. Consider the following code:
The intent of this code was to declare three variables as strings. But VBA doesn\u2019t work this way: onlyc is declared as a string\u2014the others are declared as variants. VBA requires you to explicitly declare each variable. Otherwise, it is created as a variant which is less efficient.
To make life easier for beginning developers, VBA offers the Variant data type. This data type
is very flexible because it can represent almost any type of data, and VBA automatically
handles all conversions from one type to another. But these strengths are also weaknesses.
Because the variant type must be capable of holding any type of data, it adds storage
overhead\u2014it is always more efficient to store data using a specific data type than it is to use
a variant. Also, since VBA does automatic conversions on variants, you are not in control\u2014
when conversions happen, you may see unexpected results.
Most of Microsoft\u2019s Basic variants offer the quaint (and archaic) type declaration character. By
putting one of these pre-defined characters at the end of a variable or function name, you
define the variable\u2019s type or the function\u2019s return value. For example, the following line of
declares a variable called CName as a string. The dollar sign ($) character at the end is a
type declaration character, and Access knows that a dollar sign signifies a string variable. The
problem is that type declaration characters are old-fashioned. They still exist in VBA today
primarily for backward compatibility. Good VBA code should avoid type declaration characters
because they are considered obsolete. Also, there are only type declaration characters for a
small subset of the data types that VBA supports.
All VBA variables and procedures arescoped to be available to different portions of the
program. For example, a variable declared as Public in a standard Access module can be read
or assigned from any procedure in any module in the database. This is the broadest possible
scope. On the other hand, a variable declared as Private within a procedure or passed as a
procedure parameter has the narrowest scope\u2014it is only seen by the procedure. Between
these two extremes, you also have module level scoping. When deciding on the scope of a
variable, use the narrowest scope possible. If the variable only needs to be used by one
procedure, make it private to that procedure. If the variable must be seen by many
This action might not be possible to undo. Are you sure you want to continue?