Page 29 - The Art of Designing Embedded Systems

16 THE ART OF DESIGNING EMBEDDED SYSTEMS

standards in the public domain. So, I’ve removed this excuse by including
a firmware standard in Appendix A.
Not long ago there were so many dialects of German that people in
neighboring provinces were quite unable to communicate with each other,
though they spoke the same nominal language. Today this problem is man-
ifested in our code. Though the programming languages have international
standards, unless we conform to a common way of expressing our ideas
within the language, we’re coding in personal dialects. Adopt a standard
way of writing your firmware, and reject code that strays from the
standard .
The standard ensures that all firmware developed at your company
meets minimum levels of readability and maintainability. Source code has
two equally important functions: it must work, and it must clearly commu-
nicate how it works to a future programmer, or to the future version of
yourself. Just as standard English grammar and spelling make prose read-
able, standardized coding conventions illuminate the software’s meaning.
A peril of instituting a firmware standard is the wildly diverse opin-
ions people have about inconsequential things. Indentation is a classic ex-
ample: developers will fight for months over quite minor issues. The only
important thing is to make a decision. “We are going to indent in this man-
ner. Period.” Codify it in the standard, and then hold all of the developers
to those rules.

Step 3: Use Code Inspections
There is a silver bullet that can drastically improve the rate at which
you develop code while also reducing bugs. Though this bit of magic can
reduce debugging time by an easy factor of 10 or more, despite the fact that
it’s a technique well known since 1976, and even though neither tools nor
expensive new resources are needed, few embedded folks use it.
Formal Code Inspections are probably the most important tool you
can use to get your code out faster with fewer bugs. The inspection plays
on the well-known fact that “two heads are better than one.” The goal is to
identify and remove bugs before testing the code.
Those that are aware of the method often reject it because of the as-
sumed “hassle factor.” Usually few developers are aware of the benefits that
have been so carefully quantified over time. Let’s look at some of the data.
The very best of inspection practices yield stunning results. For ex-
ample, IBM manages to remove 82% of all defects before testing
even starts!