Other Topics > Smart Access 1996-2006 > Nov-2002 > No More Write-only Code

No More Write-only Code

<< Click to Display Table of Contents >>

Navigation:  Other Topics > Smart Access 1996-2006 > Nov-2002 >

No More Write-only Code

 

Peter Vogel

 

Peter Vogel takes a quick look at two topics that will help you

create code that can be maintained: error handling and

program documentation.

 

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

understand them.

 

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.

 

Error handling

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:

 

Public Sub..

On Error GoTo ErrorRoutine

…potential problem…

Exit Sub

ErrorRoutine:

…error handling code…

Exit Sub

End Sub

 

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:

 

Public Sub..

On Error Resume Next

…potential problem…

If err.Number > 0 Then

…error handling code…

err.Clear

End If

End Sub

 

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 successors.

 

Commenting

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:

No More Write-only Code