Preventing Bugs Before They Occur

?á?á?á Perhaps the
best way to fix a bug is to keep the bug from happening in the first
place.?á For the most part, the techniques for preventing bugs are common
sense things (or would be common sense if common sense were common) that most
programmers would do if they took the time to think about it.?á But let's
face it, with increasing demands on our time, we don't always have the time we
need to pay such attention to detail!

USING OPTION EXPLICIT

?á?á?á Most
programming languages in use today require that you declare a variable before
you use it.?á In some languages, declaring variables is done to make it
easier to write the compiler.?á With other languages, programmers declare
variables just for documentation purposes; others do it simply because it was
always done that way.?á But I've found that declaring a variable does two
things: it ensures that you get the variable type you want, and it prevents you
from misspelling the variable's name.?á Sometimes, finding a misspelled
variable can be very difficult, since Clock and C1ock look the
same to you and me but not to the compiler.?á By default, Visual Basic will
create a variable automatically the first time you use it.?á To disable this
feature, you need to include Option Explicit at the top of each module in you
program.?á For new projects, you can set the Visual Basic IDE option Require
Variable Declaration (in the Options dialog box).?á For existing projects,
you can simply enter Option Explicit into the Global Declaration section of any
module.?á The big limitation of Option Explicit is that it applies only to a
given module, not to the entire project.?á So in a complex project with a
lot of forms and classes, you need to ensure that each module has Option
Explicit included.?á?á

APPLYING THE KISS PRINCIPLE

?á?á?á A
long time ago, I learned about the old KISS (Keep It Simple, Stu--pid)
principle.?á In the case of Visual Basic, the idea is that, in the long run,
an overly complex program will cause more problems than a simple program.?á
A simple program is easier to understand, thus making later modifications and
debugging a whole lot easier (especially if someone else is doing those
modifications).?á A simple program may even be more efficient, since it is
not carrying around a lot of baggage caused by extra features that aren't
used.?á The simple-is-better philosophy does not always work, however.?á
A heap sort is more complex than a bubble sort, but the results are often worth
it.?á Yet, true believers in the KISS principle will say that using a
prepackaged sort routine will give you even better results with less code to go
wrong.

APPLYING THE SMILE PRINCIPLE

?á?á?á Like
very complex programs, large blocks of code can also lead to problems.?á
Someone once told me that if you can't see an entire subroutine or function,
then it's too large.?á I call this the SMILE (Simple Makes It Lots Easier)
principle.?á Typically, I'll try to fit the entire routine in about 30
lines.?á So, if I can't fit the code into that 30 lines, I'll divide the
code into a few private subroutines and call them from the original.?á
Occasionally, I find that I want to use a large subroutine.?á This usually
happens when I have many assignment statements or subroutine calls, or I have a
Select Case statement or If ... Then ... ElseIf statement with many individual
conditions.?á In the first situation, I try to group the statements into
meaningful chunks.?á In the second situation, I try to limit myself to less
than a dozen statements in each of the individual cases.?á?á

TAKING ADVANTAGE OF OBJECT-ORIENTED
PROGRAMMING

?á?á?á Object-oriented
programming means many things to many people (especially those in the marketing
department).?á The answer to the question "Is Visual Basic
object-oriented?" doesn't really matter.?á What matters is that when
you break your program into chunks, you programs become more reliable.?á By
using well-defined interfaces, you are forced to think about how the chunk will
be used.?á Since you can't cross boundaries and change a particular value
inside a chunk even though you think it's safe, you may need to include an
additional interface in the future.?á But at least you will know all of the
code that could possibly modify the chunk's data.?á So if the chunk's data
gets corrupted, this approach simplifies the debugging process
considerably.?á The other advantage of chunks is that they are easy to build
and easy to test by themselves.?á Once they have been tested, you can build
other components using these chunks.?á Since your chunks communicate through
well defined interfaces, you can check for invalid parameters and trap more
errors before they occur.?á Of course, you also get the fundamental
advantage of object-oriented programming.?á When you need to change an
object's architecture, your existing program will continue to work without
changes, as long as the interfaces continue to work the same way.?á Also,
you can use the object in more than one place, which will help to reduce your
overall programming effort.?á?á

USING COMMENTS AND CODING
CONVENTIONS

?á?á?á Comments
and coding conventions are also important to minimizing problems in you
code.?á While these things may not prevent bugs per se, they will help the
next person who comes along to understand what you did and why you did it.?á
Then if something should go wrong, it will be easier for that next person to
rectify the problem.?á There is more to writing comments than simply
repeating what is obvious from reading the code.?á Writing good comments
takes a little time and some thought, but the end result should be useful to
anyone (including yourself) who may read those comments in the
future.?á?á

FOLLOWING CODING CONVENTIONS

?á?á?á Coding
conventions are another useful tool for preventing bugs.?á Coding
conventions come in a couple of forms: they provide rules for naming variables
and routines, and they identify which statements you want to avoid while
programming.?á Both forms combine to create a style that must be comfortable
for you to use.?á?á

?á?á?á VARIABLE AND
ROUTINE NAMES

?á?á?á Microsoft
recommends a rather complex way to prefix variables.?á While this convention
conveys a lot of information about your variables, it makes them somewhat
unreadable and definitely difficult to remember.?á Even though Microsoft
makes this suggestion, you might notice that the properties for things like the
TextBox and ListBox controls refer to the Text property rather than the strText
property.?á The same goes for the rest of the properties and methods for the
other controls and objects.?á I suggest that you use meaningful names but
leave the type information off the variable name.?á Subroutines and
functions are two places where the more descriptive you make the name, the less
likely you are to use the wrong one.?á Properties, methods, and events in
your own user controls should also be descriptive.?á After all, when you
compile your program into machine code, it doesn't matter in the least whether
you used two characters or twenty characters!?á?á?á

?á?á?á STATEMENTS TO
AVOID

?á?á?á Visual
Basic includes a variety of different statements, many of which overlap other
statements in terms of functionality.?á I strongly suggest that you choose a
subset of these statements and use them, while ignoring the others.?á This
means you'll need to remember the syntax for fewer statements, and you'll become
more comfortable with the ways that you use those statements.?á For
instance, you can use For/Next, Do Until/Loop, Do While/Loop, and While/Wend to
perform loops in your code.?á There is no reason to use all four.?á I
suggest you pick one style and use it consistently.?á Personally, I prefer
the Do While/Loop structure, but I find myself using the For/Next anytime I'm
dealing with a collection of objects (For Each), or when I need to perform a
process a fixed number of times (For I = 1 to 10).?á I never use the Do
Until/Loop or the While/Wend statements.?á I also recommend avoiding the
Gosub/Return statement and the GoTo statement.?á Both are holdovers from
BASIC's early days.?á Gosub/Return isn't really needed in Visual Basic,
where you can declare real subroutines, and GoTo is against every structured
programming rule ever written.?á I've debugged many programs written by
various programmers who used the GoTo statement, and I've frequently found it
faster to rewrite the entire program rather that try to fix it.?á?á

BEING A LAZY PROGRAMMER

?á?á?á After reading
about the KISS and SMILE principles, object-oriented programming, and comments
and coding conventions, you may be wondering, "What does this have to do
with debugging my programs?"?á The answer is that following good, solid
programming practices is key to creating programs that require less debugging
and that can more easily be debugged.?á As long as I'm on my soapbox, I'm
going to suggest a general philosophy that will help you eliminate bugs before
they become bugs.?á I call it the Lazy Programmer approach.?á Here are
the Ten Commandments of a Lazy Programmer:

?á?á?á 1.)?á Think
about what you want to do before you write any code.

?á?á?á 2.)?á Make it
work the first time - you prefer not to do it again.

?á?á?á 3.)?á Don't
make a program more complicated than necessary because this may introduce more
problems into the program in the long run.

?á?á?á 4.)?á Write
modular programs because they are easier to test and debug.

?á?á?á 5.)?á Use a
wide variety of tools to reduce the amount of work required to create the program
and to increase the reliability of the final product.

?á?á 6.)?á Reuse code
where possible, since the code has already been written and is known to work
properly.

?á?á 7.)?á Write the
least amount of code to solve the problem.

?á?á 8.)?á Use a lot of
comments for complex code, and make sure that you provide a good overview of how
the program functions.

?á?á 9.)?á Use good
coding conventions so that comments aren't necessary for simple tasks.

?á?á 10.)?á Use Visual
Basic to write Windows programs.?á