Customer Reviews

Embedded C Coding Standard

5 star:		(5)
4 star:		(0)
3 star:		(2)
2 star:		(0)
1 star:		(1)

 

 

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.

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".

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!

At 89 pages, paperback, large-print double-spaced font, it is probably the most expensive book per ounce ever. Don't be shocked when the tiny 1/4-inch thick book arrives. Instead, think of the content you are buying; it's very good. The lessons taught and rules preached are very valuable.

Minor criticisms: The writing is rough. Some references are out of date (e.g. MISRA98 is quoted and MISRA-C:2004 is the current standard). Things you want to know more about are not footnoted and things you don't care about are.

Alternatively, you can get almost the same thing free on the internet. For example Jack Ganssle [...]) has a style guide/standard that mostly agrees with this one, but it's not as complete, more verbose and folksy.

If you do buy this book, only get one copy. Follow the book's copyright notice to learn how you can use it throughout your organization. Or contact the publisher and ask about their multi-copy discount.

You'd think they could offer it for $5, sell 100x more copies, make more money, get fantastic advertising and become known as the forefather of the embedded C coding standard.

Overall, a good book. I was quite pleased with this purchase, but it was my employer's money and not mine!

Too often I've seen code written without any adherence to standards. It leads to poor maintainability, bugs, and a host of other issues. This standard makes source code very readable, helps greatly with portability, and minimizes bugs that come from many developers using styles that may clash, causing code to be interpreted incorrectly. Highly recommended. Will definitely make great use of this standard.

This book does seem a good bit overpriced for what you get (but is available for much less {$29 shipped} at the author's web-site).
Like most programmers I have my own personal coding standards, but I'm also forced to follow other standards for different projects. I decided to get this book in the hopes that it would introduce me to some new ideas that I could incorporate into my own standards. I was glad to find a few new ideas for my own coding standards, but not a whole lot. Of course, I also don't agree with all of his standards.
This book could have been improved greatly with a few more examples to illustrate some of the easy ways bad things can happen if particular rules weren't followed.

Much of this information is on the Netrino website so I was expecting much more that what's actually in the book.
Price should be half.

I recently purchased the "Embedded C Coding Standard" book a year ago or so. It's the best standard I've seen for developing firmware in C. I've read Michael's "Programming Embedded Systems in C and C++" and loved it. It's the reason I purchased his embedded coding standard book. We'll eventually use "Embedded C Coding Standard" to help us define and extend our in-house coding standards.