Hello there!This post is a review of Michael Barr's Embedded C Coding Standard book.
First of all, why a c coding standard? I have been working in my life in small and medium companies and in most of them, we always had the same problem. No c coding standard. Everyone had their own standard and very often, those standard are not standard, because it used to change every project. Every time some one quit the company, it's always the same problem: code badly written, no comments, hard to read, hard to understand and overall hard to maintain.
So this book is a very good start point for those who works in a company which doesn't have a standard and want to deploy one.
First Michael Barr make clear that the code written is a property of the company and not of the programmer. A standard code eliminates conflict over items that are sometimes viewed as personal stylistic preferences.
Yet, a standard can prevent some bugs because it forces a programmer to follow some good practices that people normally doesn't do, like always open and close braces, even in a if with only one statement.
Indeed, this book shows some goods practices like:
- Never leave a code with comments. We should comment code with #if 0
- Use inline functions instead of macros
- Always use parentheses and don't rely in C's operator precedence
- Use of doxygen to document code
- Create the comments before begins to code once we have to know what the functions must do before start coding.
Of course there are some suggestions that I'm not agree like:
- Use only 80 columns for code
- Use goto, continue or break.
We can always adapt this standard. The most important thing is to have one and follow it. For sure it will save you several hours of debugging and it will improve your code quality.
Marcelo
