Development must start from a firm written specification. The Cleanroom method is intended to insure that the code conforms to the specification.
You will start by describing the interface to a module (program or piece of a program) using intended function notation. Then you will write the code in such a way that it clearly implements the intended function.
We use the term prime, short for primary program refinement, to describe each of the pieces, the black boxes of our design.
Here is the flow of the design and verification of one prime.
Write the intended function for the prime.
Write the code that implements that intended function.
Sometimes the prime will be a single block of code with no control flow. However, more generally, the code will require some control logic. Only four control structures are permitted, and each is associated with a procedure for proving its correctness.
true, then do
While loop: While
Definite iteration: For every
For each of these control structures, you will write an
intended function for the pieces (such as the body of a
while loop) and write the code for that
piece to conform to that intended function.
The designer may self-review the code by various methods, such as trace tables that show the state at various locations in the code.
The code is verified by peer review. Unless every member of the review panel is completely convinced that the code matches the intended function, the code is sent back for rework.
Notice that the peer review is much more stringent than classical design reviews. Your author has been through quite a few of those while working in industry. In the classical process, whoever wrote the code presents it to peers, who strive valiantly to stay awake. After droning on for a few hundred lines, the presenter says, “Any questions?” If you ask too many questions, especially as lunchtime approaches, you may find your coworkers glaring at you.
No, in a Cleanroom peer review, the code must be obvious or it gets sent back for rework. This has the advantage of preventing unnecessary cleverness. In the author's experience, cleverness is seldom really required.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
|-- Brian Kernighan, professor at Princeton University, one of the inventors of Unix, and co-author of The C Programming Language.|
More people looking at the code will catch more mistakes, and earlier in the process. Anyone who has done much proofreading will tell you that the author will have the same blind spots during proofreading that they had when they wrote it, so a different viewpoint helps find and clean up defects.
The methodology also motivates you to divide things into more, smaller pieces. Monster procedures are hard to verify. Peer review of a small, well-defined module doesn't take very long.