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.
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?).
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 .
Some information on inspections is available on-line; of particular
note is the WWW
Formal Technical Review Archive
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
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:
- 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).
- 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.
- 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.
- 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.
- 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?
- 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.
- 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.
- Missing "reverse" keyword in a backward "for" loop. You should say:
for I in reverse 1..5
- Tasks exposed to unexpected exceptions.
If a task does not catch exceptions the task will terminate on one.
- 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?
- Learn about a program and discuss possible improvements.
- Detect defects.
- Fix defects.
- Spend endless hours in useless meetings.
You may also:
David A. Wheeler (firstname.lastname@example.org)