Rule: The comma (‘,’) operator shall not be used within variable declarations.

Example (don’t):

char * x, y;   // did you want y to be a pointer or not?

Reasoning: The cost of placing each declaration on a line of its own is low. By contrast, the risk that you’ve made a mistake and the compiler or a maintainer won’t understand your intentions is high.

Coding Standard Rule #9

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

Rule: Parameterized macros shall not be used if an inline function can be written to accomplish the same task.

Example:

#define MAX(A, B)   ((A) > (B) ? (A) : (B))     // Don’t do this ...inline int max(int a, int b)           // ... if you can do this instead.

Reasoning: There are a lot of risks associated with the use of preprocessor #defines, and many of them relate to the creation of parameterized macros. The extensive use of parentheses (as shown in the example) is important, but does not eliminate the unintended double increment possibility of a call such as MAX(i++, j++). Other risks of macro misuse include comparison of signed and unsigned data or any test of floating-point data. The C++ keyword inline was added to the C standard in the 1999 ISO update.

Coding Standard Rule #8
Coding Standard Rule #10

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

Rule: Signed integers shall not be combined with unsigned integers in comparisons or expressions. In support of this, decimal constants meant to be unsigned should be declared with a ‘u’ at the end.

Example (don’t):

uint8_t a = 6u;
int8_t b = -9;

if (a + b < 4)
{
// This correct path should be executed
// if -9 + 6 were -3 < 4, as anticipated.
}
else
{
// This incorrect path is actually executed
// because -9 + 6 becomes (0xFF – 9) + 6 = 252.
}

Reasoning: Several details of the manipulation of binary data within signed integer containers are implementation-defined behaviors of the C standard. Additionally, the results of mixing signed and unsigned data can lead to data-dependent bugs.

Coding Standard Rule #7
Coding Standard Rule #9

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

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

Rule: Whenever the width, in bits or bytes, of an integer value matters in the program, fixed width data types shall be used in place of char, short, int, long, or long long. The signed and unsigned fixed width integer types shall be as shown in the table below.

Reasoning: The ISO C standard allows implementation-defined widths for char, short, int, long, and long long types, which leads to portability problems. Though the 1999 standard did not change this underlying issue, it did introduce the uniform type names shown in the table, which are defined in the new header file stdint.h. These are the names to use even if you have to create the typdefs by hand.

Coding Standard Rule #5
Coding Standard Rule #7

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