Peter Vogel takes a quick look at two topics that will help you
create code that can be maintained: error handling and
BACK when I started writing code, the battle over
structured code was just in the process of
wrapping up (structured programming won).
That didn’t stop me from writing a lot of “write-only”
code with two-letter variable names, no comments, and
GoTos. My excuse is that I was writing in AppleBasic
on an Apple IIe with 48KB of memory. Gerry Weinberg
commented once that many earlier programs were
really love letters from the programmer to the computer.
And, like all love letters, they were so full of inside
jokes and pet phrases that only the two lovers could
Of course, back then the emphasis was on building
programs—which, sadly enough, it still is. Yet we know
that we spend far more time modifying programs
already in production than we do writing totally new
programs. Typical estimates suggest that 65 to 75 percent
of a developer’s time is spent in working on existing
applications. “Write-only” programs are the bane of
efficient and effective system maintenance. Being able to
understand what was meant by the previous programmer
is critical to being able to fix or enhance an application.
And, of course, six months after you write some code you
will be “the previous programmer,” even when you’re
reading your own code.
There aren’t any rules for writing readable code.
Writing readable code is more about the attitude that you
take when you write than a particular set of rules. In this
article I’ll discuss two topics that will let me illustrate the
kinds of things that you can do in order to create readable
code: error handling and commenting.
In his article in this month’s issue, Keith Bombard
stresses the importance of error handling. In VBA
environments, error handling has been limited to the
On Error construct. One way to use VBA error handling
is like this:
On Error GoTo ErrorRoutine
…error handling code…
The readability problem with this strategy doesn’t
become obvious just by looking at this skeleton. The
problem that exists is in the distance that may separate
the code between the “...potential problem...” section
and the “...error handling code...” area. Separating two
sections of code that are as tightly related as a line of code
and its error handler makes it harder to understand how
they relate to each other.
For the past five or six years I’ve been writing my
error handling code this way:
On Error Resume Next
If err.Number > 0 Then
…error handling code…
Using this error handling strategy, my error
handling code can immediately follow the code that may
invoke it. The point that I’m trying to make is that I didn’t
adopt this style because it was more efficient. My only
reason for using On Error Resume Next was that I
believed that it would make it easier for others (and me)
to read my code.
It’s not a perfect solution (of course, when you start
off assuming that you have an error, it’s hard to be
perfect). The Try...Catch processing that’s introduced
with Visual Basic .NET is a cleaner solution. In the
meantime, this is what I’m doing to make life easier for
My bosses always told me that I should comment my
code. They never told me what that meant, but they were
confident that I should do it.
At one time there was an ongoing argument about
what the right ratio of lines of code per comment line
was. In the end, people realized that the problem wasn’t
about the quantity of comments but the quality of the
comments. To paraphrase Kernighan and Plauger in
their classic work, The Elements of Programming Style, the
value of a comment is zero or negative if it’s wrong.
Read more here: