This is the fifth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.

Rule: Comments shall neither be nested nor used to disable a block of code, even temporarily. To temporarily disable a block of code, use the preprocessor’s conditional compilation feature (e.g., #if 0 … #endif).

Example (don’t):
/*
a = a + 1;

/* comment */
b = b + 1;
*/

Reasoning: Nested comments and commented-out code both run the risk of allowing unexpected snippets of code to be compiled into the final executable. This can happen, for example, in the case of sequences such as the above.

Coding Standard Rule #4
Coding Standard Rule #6

These rules are excerpts from the Embedded C Coding Standard book.

This is the fourth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.

Rule: The volatile keyword shall be used whenever appropriate, including:

• To declare a global variable accessible (by current use or scope) by any interrupt service routine,
• To declare a global variable accessible (by current use or scope) by two or more tasks, and
• To declare a pointer to a memory-mapped I/O peripheral register set (e.g., timer_t volatile * const p_timer ).

Reasoning: Proper use of volatile eliminates a whole class of difficult-to-detect bugs by preventing the compiler from making optimizations that would eliminate requested reads or writes to variables or registers that may be changed at any time by a parallel-running entity.

Anecdotal evidence suggests that programmers unfamiliar with the volatile keyword think their compiler’s optimization feature is more broken than helpful and disable optimization. The authors suspect, based on experience consulting with numerous companies, that the vast majority of embedded systems contain bugs waiting to happen due to a shortage of volatile keywords. These kinds of bugs often exhibit themselves as “glitches” or only after changes are made to a “proven” code base.

Coding Standard Rule #3
Coding Standard Rule #5

These rules are excerpts from the Embedded C Coding Standard book.

The third in a continuing series of blog posts about simple rules for keeping bugs out of embedded software written in the C programming language.

Rule: C’s static keyword shall be used to declare all functions and variables that do not need to be visible outside of the module in which they are declared.

Reasoning: C’s static keyword has several meanings. At the module-level, global variables and functions declared static are protected from inadvertent access from other modules. Heavy-handed use of static in this way thus decreases coupling and furthers encapsulation.

Coding Standard Rule #2
Coding Standard Rule #4

These rules are excerpts from the Embedded C Coding Standard book.

Another in a continuing series of blog posts about simple rules for keeping bugs out of embedded software written in the C programming language.

Rule: The const keyword shall be used whenever possible, including:

• To declare variables that should not be changed after initialization,
• To define call-by-reference function parameters that should not be modified (e.g., char const * p_data),
• To define fields in structs and unions that cannot be modified (e.g., in a struct overlay for memory-mapped I/O peripheral registers), and
• As a strongly typed alternative to #define for numerical constants.

Reasoning: The upside of using const as much as possible is compiler-enforced protection from unintended writes to data that should be read-only.

Coding Standard Rule #1
Coding Standard Rule #3

These rules are excerpts from the Embedded C Coding Standard book.