Page 33 - The Art of Designing Embedded Systems

20 THE ART OF DESIGNING EMBEDDED SYSTEMS

processes (before the team members are truly comfortable with it) is to
have the Author supply a pizza for the meeting. Then he seems like the
good guy.
At this meeting, make no attempt to rework the code or to come up
with alternative approaches. Just find errors and log them; let the Author
deal with implementing solutions. The Moderator must keep the meeting
fast-paced and efficient.
Note that comment lines require as much review as code lines. Mis-
spellings, lousy grammar, and poor communication of ideas are as deadly
in comments as outright bugs in code. Firmware must work, and it must
also communicate its meaning. The comments are a critical part of this and
deserve as much attention as the code itself.
It’s worthwhile to compare the size of the code to the estimate origi-
nally produced (if any!) when the project was scheduled. If it varies sig-
nificantly from the estimate, figure out why, so you can learn from your
estimation process.
Limit inspection meetings to a maximum of two hours. At the con-
clusion of the review of each function decide whether the code should be
accepted as is or sent back for rework.
Rework-The Author makes all suggested corrections, gets a clean
compile (and Lint if used) and sends it back to the Moderator.
Follow-up-The Moderator checks the reworked code. Once the
Moderator is satisfied, the inspection is formally complete and the code
may be tested.

Other Points
One hidden benefit of Code Inspections is their intrinsic advertising
value. We talk about software reuse, while all too often failing spectacu-
larly at it. Reuse is certainly tough, requiring lots of discipline. One reason
reuse fails, though, is simply because people don’t know a particular chunk
of code exists. If you don’t know there’s a function on the shelf, ready to
rock ’n’ roll, then there’s no chance you’ll reuse it. When four people in-
spect code, four people have some level of buy-in to that software, and all
four will generally realize the function exists.
The literature is full of the pros and cons of inspecting code before
you get a clean compile. My feeling is that the compiler is nothing more
than a tool, one that very cheaply and quickly picks up the stupid, silly er-
rors we all make. Compile first and use a Lint tool to find other problems.
Let the tools-not expensive people-pick up the simple mistakes.
I also helieve that the only good compile is a clean compile. No error
messages. No warning messages. Warnings are deadly when some other