More Bug-Killing Rules
Here are more examples of coding standard rules you can follow to reduce or eliminate certain types of firmware bugs.

Rule #11: The keywords short and long shall not be used.

Reasoning: The ANSI/ISO C standard contains a set of strict requirements plus mere guidelines for the authors of C compilers. Among the guidelines (also known as "implementation-defined" behaviors) are the precise width, in bits, of the char, short, int, and long data types. ISO C mandates that variables of type short must hold at least 16 bits and long at least 32 bits, across all platforms. Other than that, the only strict requirement is that sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long). There are times when you must use char (see Rule #12). In other places (e.g., loop counter declarations), it makes sense to allow the compiler to choose the best/fastest width using int. But in keeping with Rule #6 concerning adoption of the C99 fixed-width integer types/names, it is appropriate to ban use of the short and long types altogether. Like the semi-colon followed by left-brace sequence above, an automated tool can be used to enforce this rule.

Rule #12: Use of the keyword char shall be restricted to the declaration of and operations concerning strings.

Reasoning: Among the implementation-defined behaviors of C is the signed-ness of a char data type. One compiler may treat your char variables as unsigned, another as signed--and yet both are technically ISO C compliant! This introduces subtle and potentially hidden risks related to using the bit-wise operators on signed char data (Rule #7) or mixing signed and unsigned data (Rule #8). The risk of bugs derived from this subtlety of C are entirely eliminated by choosing int8_t or uint8_t explicitly whenever the data is other than part or all of a string.