Read the article here: Bug-killing standards for firmware coding

For rule #8, your example is bad - integer promotion will ensure that the uint8_t a is promoted to (int) 6, and int8_t b is promoted to (int) -9. The constant "4" is already an int (whether you like it or not), so the comparison will be done correctly as the programmer expected.

The advice is sound, however - be wary of mixing signed and unsigned numbers. Sometimes things won't work as expected, and sometimes you end up with unwanted promotions (if you add a uint16_t to a int16_t on an 8-bit processor, you'll not be pleased when the compiler follows the C standards rules and promotes then both to int32_t).

The matching brace style is superior to the one true brace style since it is easier for the programmer to see how the braces are matched throughout the development and maintenance of a program.

The one instance cited, elimination of ;{ does not override the deficits of this styles' deficiencies.

Block bracing makes for far more maintainable code than the one brace style as it makes the structure of your program far more visible on a line by line basis. White space in a program is your friend and having matching braces makes for easier determination of the correctness of code grouping.

We may have to agree to disagree on this one!

Yes Peter, we will have to agree to disagree, although I strongly agree that white space is your friend. However, once you change to 1TB you will find that the structure of your code is probably more visible than it was with the Allman style, as long as you indent your code:
while (condition) {
indented code line 1
indented code line 2
}
The way to think of this is that the right brace ends the while. The indented code is obviously within the scope of the while. Since proper coding style requires that the while aways has a right brace on the same line (no single-line while statements), the structure of the code highly visible and completely unambiguous. It may take a while to get used to the 1TB mindset, but you will never go back. Trust me on this one.

It is interesting to see how one's prior experience influences one's perception of what good coding style is. The first structured high-level language I used was PL/M-86, which -- if memory serves -- used "DO" and "END" to delimit blocks of code. I preferred to place the "DO" on a line of its own, but one of my coworkers did not. I occasionally had to review or debug his code, and I found it difficult to match a "DO" with its corresponding "END". So, when I made the transition to Pascal and later to C, I retained a preference for keeping the opening delimiter of a code block on its own line. I have debugged many lines of other people's code and have never found a bug like the one Dale describes. Such bugs are easily prevented if the coding style insists that controlling statements must always be on a separate line from the statement or code block they control, even if only an empty statement is needed.

A particularly obscure construct that seems to be part of the 1TB style is "} else {" all on one line. That not only makes it difficult to match curly braces in pairs, but also to match an "if" with its corresponding "else".

C was developed in the days when the teletype and similarly slow devices were used for input and, sometimes, also for code listings. Therefore, it includes a number of elements that allow for very terse code. Now that input devices are much faster and code listings tend not even to be generated or needed, good style should probably prohibit the use of many of those elements. For example, embedding an assignment in the condition of an "if" statement should be discouraged, as should the use of the pre- and post-increment and -decrement operators within the parameters being passed to a function or during pointer dereferencing. It takes more characters and more lines of code, but clarity is vastly improved, and many opportunities for bugs are removed.

I had exactly the same experience as Dale, regarding 1TB.
And just a few days ago I downloaded sample code from TI which contained the bug Dale mentions.
1TB apart, I liked the article very much. It shows the way to go.

Rule 5

It sure would be nice if the #if 0 ... #else ...#endif would be recognized by my IDE and be coloured so that I know it's not code. /*...*/ all goes green and comment like, so I know it's not the version I'm using today.

Hmm, there's probably a way to do it, CodeWright allowed me to set up keywords so Codewarrior must...

Many embedded target C compilers have selectable MISRA rules checks to catch such issues. Also running other static analysis tools will flag out potential bugs. For many of our projects, we have included static analysis with MISRA rules checks for clean source code check-in.

-Will