Embedded C Coding Standard [Paperback]

This book carefully lays out a detailed set of rules for embedded software development. These rules draw on a variety of sources and are backed up by practical sound logic in terms of why they should be observed and how they should be applied. There are many subtleties associated with embedded software development that the text specifically calls out through the use of a "Zero Bugs Period" logo. The author has also taken the time to illustrate key concepts by including numerous code fragments that are simple and straight forward to understand. Given my personal experience in embedded software development within small and large companies over the last twenty-five years; I would highly recommend this book to any individual or team that wishes to dramatically improve the quality of their embedded software and standardize on a consistent "Look and Feel" that can be easily shared across a company spanning multiple geographies.

The first thing to note about any standard is that you ain't gonna make everyone happy by publishing a standard that says DO THIS and ONLY THIS, EVERY TIME. By their very nature, programmers of all types have to question everything they come into contact with...all of the time. When the law is laid down, few programmers like it. Standards for coding are lax or non-existent because of this basic fact. When standards are lax, code quality suffers. Fact of life. Don't shoot the messenger.

For example, one of the MUST DO things in this standard is that the "keywords if, else, while, for, switch and return" will always have one space between the keyword and the left parenthesis. Surely one can argue that this is purely stylistic. Today's modern editors obviously syntax highlight keywords, so why the need for a requirement that stipulates such things? The argument continues with "why should I have to type a space when I know these simple keywords forwards and backwards?"

The answer to that question is the reason for every company to use a solid, published standard particularly when it comes to writing embedded C code. When one considers that C practically owns the embedded world in terms of supported "high level language" compilers, not using a quality, published standard should be considered a flagrant violation of your customer's trust. While not everyone will agree with every statement in the standard, as published nor accept the rational presented occasionally as "Reasoning," quality programmers SHOULD take note that this standard is an evolution of lessons learned by a variety of embedded systems experts and collected herein for your convenience.

I strongly encourage those developing embedded systems to establish and use a standard, any standard. If you don't already have one in your environment, use this one. Please. If you already have one, compare it to this one and see if this isn't a better choice. It probably is.

Again, I don't blindly accept everything that it says on faith alone. There are a NUMBER of areas in the standard, as published, that I would have liked to have seen more Reasoning or at least a sentence or two of reasoning. Sometimes the reasoning isn't included, such as is the case in the use of whitespace for the previously mentioned keywords.

Consistency is the key to any form of programming. And this book intends to help all embedded C programmers produce consistent code!

If you are a program manager, project manager or team lead of an embedded systems project, get this book, give a copy to everyone on your team and use it ragged until your team produces consistent code. You can not go wrong using the standard supplied by this book and there are many, many ways to go wrong using some other standard or none at all.

For anyone who MUST deviate from the standard for whatever sound reasoning would have to apply, there is a section on deviation that even tells how and when to deviate. A truly useful standard SHOULD be inflexible as much as possible in this embedded systems world of ours. When we "bend the rules" we take on more risk and we discard the lessons learned by the many who have come before us.

The book is not an exhaustive representation of standards for C programming, rather, it is a concise, mostly explicit standard for embedded C programmers. If the sheer weight of a volume suggests its value, this probably won't live up to your girth requirements. At something under 100 pages, it, like embedded software should, gets right to the point, stays on target and gets out cleanly. I'd probably advise the inclusion of an index, but it isn't really that challenging to find the topics of interest by flipping through the pages via the manual scan method.

The book is very clear on a wide variety of conventions, including many largely considered stylistic or a matter of convention that will (that's WILL) differ from what you may be used to seeing in code. If that is going to bother you, you may want to remain happily ignorant of the value brought to the table by this book. However, if you're seeking a suitable, useful coding standard for hardcore embedded systems programming in C, look no further.

I'd like to see this standard adopted by EE programs, but that would suggest that more than a single semester of C would be part of the curricula. You can help in your department by bringing it to the right audience. The potential for reducing and perhaps someday eliminating embedded systems bugs is on the horizon!

This 89 page minibook, printed in the largest font of any technical book I have read, is instantly unimpressive. I cannot say I learned a single thing from this book.

If you can write drivel in a font appropriate for children, and sell it for the same price a "real" technical book sells for, that is a way to make a fast buck.

But there will not be any follow-on purchases of other titles from this author after you get a look at this offering.

An example of one of his "rules".... No variable name shall contain any upper case letters. So much for hungarian notation.

I say save your money, and buy a copy of "Writing Solid Code", or "Code Complete".