Release checklist for programs

This article presents a code review checklist to go through before releasing a program to users.

High software quality requires extensive testing. Unfortunately, no amount of testing can reveal all errors. Code review can find problems that testing can't. The code review can be done manually or with automated code audit software.

This article presents a short checklist to review before releasing a new version of a program. It's a quick list that doesn't require extensive effort to go through, so that the checks can be performed before each minor release. More extensive code review should be performed from time to time to optimize the program further, to locate hidden bugs and to reduce maintenance efforts.

The checklist focuses at Windows programs written in Visual Basic, but you can use it with many other programming languages and environments as well.

In this article:

Project Analyzer is a VB code review tool that can be used as an automated checklist verification tool. It supports all the review rules mentioned in this article.

Remove unused modules

Many programs contain parts that are not in use. These unused parts are called dead code. The amount of dead code in a "dirty" program can well be something like 30-40%. Complete dead code removal is a demanding task. Ideally, it should be done at regular intervals. Fortunately, not all dead code is equally bad. You can remove the more problematic parts and decide to keep an acceptable level of dead code.

At a minimum, remove the following types of dead code:

Remove other unused things

Review empty procedures and modules

Sometimes you find an empty procedure or an empty module. That's odd. Here is what happened:

  1. You forgot to write the code! Write it now.
    OR
  2. You deleted all the code there was. You kept the procedure (or module), because you didn't feel like removing it completely. Now it's time to delete it for good.

Fix functionality problems

Fix user interface anomalies

Now we move on to polishing the windows and dialogs. This is also an important part as it affects what the users think about your application. If the UI is not performing the way they expect, that will affect the entire user experience. Giving the UI a final polish might not be intellectually challenging for the developers, but forgetting to do it will be challenging for the users!

Note: Project Analyzer detects this group of UI problems for VB6 forms, but not for VB.NET or VBA.

Find hidden VB errors

Visual Basic allows one to use undeclared variables. They should never be used in production code, as they are a potential source of errors. Set Option Explicit on for each module to require variable declaration. This is a great way to spot typing errors and also to define proper data types for variables.

Never use a fixed file number for file access (such as in Open filename For Input As #1). If the file is accidentally left open (due to an error, perhaps), subsequent file access using the same number will fail. This may not show up during testing, even if it affects the users from time to time.

Optimize compile flags

Now that your program seems to be running fine, let's optimize a little. We're not going into detailed optimization here, just a few compiler settings to verify:

Release it!

OK, now you can compile and release your program! Good luck!

Project Analyzer is a VB code review tool that can be used as an automated checklist verification tool. It supports all the review rules mentioned in this article.