The Extra Resume: Revisited

A few days ago, I wrote an article about a technique I learned from Access MVP Armen Stein.  Here's the basic concept in visual form:

Today, someone posted a response to the article on an unlisted Access developers group on LinkedIn.  I won't quote the post publicly since it was written on a closed forum and I haven't requested their permission to do so.  However, the question raised was a thought-provoking one and is something I've been thinking about since I read it.

The poster was asking the group how they felt about pre-staging the "extra Resume." I clearly implied one should do this in my original article.

The Extra Resume: Objectively Good

First, I want to start by reaffirming an objective truth.  The extra Resume is the best way to return to the erroring line of code while debugging.  That is true for this very important reason:

It completely avoids the possibility of an infinite loop

In this way, the extra Resume is a far superior solution to commenting out the line label of an existing Resume statement.  In other words:

I think we can all agree that avoiding accidental infinite loops is a good thing.

The Extra Resume: Permanent or Temporary?

The more interesting question--and the one raised on LinkedIn--is whether it's a good idea to add the extra Resume before it's needed.  I implied this was the case in my own article with the following line:

There's no code to change when debugging

Just for fun, I'll present arguments for both sides of the case, then state my own preference at the end.

Permanent is Better

Programmers are lazy efficient.  

It's asking a lot of the typical programmer (e.g., me) to type six characters (Resume) when a single character (') will achieve the same thing.  By pre-staging the extra Resume, you relieve future programmers of the heavy burden of typing those six characters.

Additionally, the extra Resume looks weird.  But in a good way.  Hopefully, a curious programmer would see that extra Resume and it would remind them that there's a safer way to jump back to the erroring line of code than simply commenting out the Exit label at the end of the Resume statement.

But wait?  Why would adding the extra Resume to every error handler be more efficient than adding it only when needed?  The reason there's no extra up-front effort to add the extra Resume to every error handler is because you're using some sort of automated solution to add error handlers to your code (like MZ-Tools, for example).  You are doing that, right?

Temporary is Better

Programmers are efficient lazy.  

Pre-staging "shortcuts" into production code encourages other, possibly more harmful, lazy practices.  The problem, then, isn't the extra Resume per se.  Rather, the problem is the fostering of an environment that could lead to a corner-cutting mindset among programmers.  

(Note: This argument is inspired by the post on LinkedIn, though I've taken liberties in editorializing it.  Credit for the idea belongs to the LinkedIn poster; blame for any butchering of said idea is all mine.)

Furthermore, all of those extra Resume lines are not adding any semantic value to the program.  They are boilerplate code.  And, whenever possible, boilerplate code should be avoided (or at least minimized).

And the Winner Is...Temporary is Better

After weighing the pros and cons, I decided to fall back on my core programming philosophy:

My approach to software development in four words: Less noise. More signal.

In those terms, the case for Temporary is the clear winner.

And that's a shame, because now it means I'll have to learn to be less lazy in my debugging...