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.
- Use only 80 columns for code
I think that nowadays we have big screens and the IDE is much better than before, so I don’t see any problem in use more than 80 columns.
- Use goto, continue or break.
I understand that the use of this keywords can lead to “spaguetti” code, but if you really know what are you doing, I don’t think that you’ll have problems.
Marcelo
Great post Marcelo!