Section 17.5 - Software Inspections/ Reading Bugs Out

While Ada can prevent a number of software defects, no language can remove them all. One approach to increasing software quality, and reducing development cost and development time, is called software inspection. A software inspection is a rigorous review of a product by a small group of peers for the purpose of detecting defects. The work products reviewed are small - for code, up to about 250 lines would be considered in one inspection.

Inspection Process
In an inspection, each person ("inspector") is given a role during the initial planning stage, such as "moderator" (the moderator controls the inspection and is not the author). After an optional overview of the product given by the author, each inspector prepares by carefully reading the product so they completely understand it (this generally takes 1-4 hours). The inspectors then meet together for no more than two hours to detect defects together (the list is recorded for later use). Optionally, they may meet afterwards for a "third hour" to discuss possible improvements and other things not related to detecting defects. The author then goes off to fix ("rework") the defects. After the author is done, the moderator checks to make sure the fixes are okay and a reinspection may occur if necessary. Occasionally a "causal analysis" process should occur to determine common defects, their causes, and how to eliminate those causes.

Obviously, this is a pretty rigorous process. The amazing thing is that many people have documented that inspections actually reduced their total time and cost, as well as increased the resulting quality, because inspections can reduce the cost of errors and rework. Inspections aren't technically glitzy, but results are usually more important than glitz.

One good way to find more about inspections is to buy my book on inspections (how's that for a plug?). It's titled Software Inspection: An Industry Best Practice, by David A. Wheeler, Bill Brykczynski, and Reg Meeson [Wheeler 1996]; it's published by IEEE. Many papers are available on inspections; one oft-referenced paper is by Michael Fagan [1986]. Some information on inspections is available on-line; of particular note is the WWW Formal Technical Review Archive and the Software Inspection and Review Organization (SIRO) home page.

Ada and Reading Out Bugs

If you're part of an inspection of Ada code, or simply reading your own code looking for likely defects, it can help to know what are the "more common" errors of Ada programmers. In an inspection such a list is called a "checklist". Unfortunately, I'm not aware of any publically-distributable empirical data to support any specific Ada checklist. However, based on anecdotal information (such as John B. Goodenough's list of common Ada programming errors), I've come up with the following checklist which you can use as a starting point. I strongly encourage you to update this checklist to your situation as you gain experience in determining common defects in your own code.

Ada Checklist - Look For:

  1. Reading Uninitialized variables. Ada compilers often detect these, but not always. Access values are always initialized to null, and when creating your own types you can cause them to have initial values. However, for other types a variable that's not specifically given an initial value might have an arbitrary set of "garbage" bits set, and trying to use this "garbage" data later might cause problems. When declaring variables, it's often a good idea to give them a starting value where that makes sense. There's been much discussion on whether Ada should even permit uninitialized variables; the rationale permitting them is that unnecessary initializing can cause a performance hit. The safety and security annex adds pragma Normalize_Scalars, which sets uninitialized values to out-of-range values where possible (this makes it easier to detect uninitialized values).
  2. Off-by-one boundary conditions (for loop conditions, array indexing, and comparisons). This is the error of having almost the right boundary. For example, did you use < when you meant <=? Check all your comparisons and loop boundaries. Ada will raise a run-time exception if you attempt to access out-of-bounds array element, which helps in certain circumstances but not in all cases.
  3. Access type (pointer) and storage management errors (especially boundary conditions like null lists). Trying hiding access (pointer) values so only a small portion of your program has to deal with them, use initialization/finalization operations to manage your storage, and make sure you can handle "empty" cases where you should.
  4. Incorrect return values handling. For example, if a function returns a range, make sure every value in the range will be handled appropriately by your program.
  5. Incorrect special condition handling. Have you handled all cases? If you're reading from a sensor, do you deal with bogus sensor values? Do you handle all appropriate exceptions?
  6. Incorrect array bound handling. An array's lower bound is not always one, so use 'First, 'Last, 'Length, and 'Range when you're passed an array. For example, passed strings may be slices, so the first element of a String might not have the index value 1. Do not assume that 'First and 'Last are equal for different parameters or that they're the same as the base type, and use S'Length (not S'Last) to find the length.
  7. Instantiated unconstrained arrays. Arrays with large array indices (like Integer or Positive), or records containing them, must have their bounds set; few computers can have "Integer'Max" array elements.
  8. Missing "reverse" keyword in a backward "for" loop. You should say:
        for I in reverse 1..5
  9. Tasks exposed to unexpected exceptions. If a task does not catch exceptions the task will terminate on one.
  10. Invalid fairness assumptions in tasking. Some tasking operations are not guaranteed to be "fair". For example, in a selective wait with several open alternatives, Ada is free to pick between any of them each time; it need not pick between them "fairly".


What is the purpose of an inspection meeting?

  1. Learn about a program and discuss possible improvements.
  2. Detect defects.
  3. Fix defects.
  4. Spend endless hours in useless meetings.

You may also:

PREVIOUS Go back to the previous section

NEXT     Skip to the next section

OUTLINE  Go up to lesson 17 outline

David A. Wheeler (

The master copy of this file is at "".