Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Programming - 17 Steps To Better Vba Code

Programming - 17 Steps To Better Vba Code



|Views: 507|Likes:
Published by api-3766251

More info:

Published by: api-3766251 on Oct 16, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





17 Steps to Better VBA Code

by Dan Haught
Vice President of Product Development
September 11, 1997

Writing code is easy. Writing good code is hard. So what is good code anyway? Generally, we
think of the following attributes:

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.

#1: Use Option Explicit

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

Debug.Print intX + intY + intZ
End Sub

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.

With Access 95 and later, you can have Option Explicit automatically inserted into every
module you create. Search Access online help for "Options" for more information.
#2: Declare Variables Correctly

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.

Next, keep each Dim statement on its own line. Consider the following code:
Dim intX As Integer, intY, intZ As Integer

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:

Dim a, b, c As String

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.

You should also know that VBA lets you specify types for constants using this type of syntax:
Const strCustomer As String = "Customer"
#3: Avoid Variants

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.

#4: Don't Use Type Declaration Characters

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

Dim CName$

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.

You should also avoid the Def\u2026 statements, such as DefInt A-Z. These constructs are also
obsolete, and can lead to code that is difficult to debug and maintain.
#5: Use Narrow Variable Scoping

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

Activity (14)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Toma Vasile liked this
vvkvaranasi liked this
agupta12345 liked this
001bookworm liked this
smarty_gaur liked this
rusdiichal17 liked this
prohydra liked this
lyduyphuong liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->