Section 17.5 - Software Inspections/ Reading Bugs Out

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

Quiz:

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.

Go back to the previous section	Skip to the next section	Go up to lesson 17 outline

The master copy of this file is at "http://www.adahome.com/Tutorials/Lovelace/s17s5.htm".