Sign Up Now

Receive Michael Barr's Firmware Update ® newsletter for free how-to articles and industry news by e-mail. Sign up now.

Bookmark It

Bookmark this page or share it with a colleague.

Embedded C Coding Standard

Barr Group's Embedded C Coding Standard was developed from the ground up to minimize bugs in firmware, by focusing on practical rules that keep bugs out--while also improving the maintainability and portability of embedded software. The coding standard details a set of guiding principles (more below) as well as specific naming conventions and other rules for the use of data types, functions, preprocessor macros, variables and much more. Individual rules that have been demonstrated to reduce or eliminate certain types of bugs are highlighted.

The book is available for purchase by mail (price includes shipping) or e-mail (PDF); use the "Buy Now" button below to order your copy now.

Table of Contents

Embedded C Coding Standard
ISBN 1-4421-6482-4
Select Delivery Type
Clicking "Buy Now" will take you to PayPal to place your order.
  • Introduction
    • Purpose of the Standard
    • Guiding Principles (excerpt below)
    • Enforcement Procedure
    • Deviation Procedure
  • 1. General Rules
    • 1.1 Which C?
    • 1.2 Line Width
    • 1.3 Braces
    • 1.4 Parentheses
    • 1.5 Common Abbreviations
    • 1.6 Casts
    • 1.7 Keywords to Avoid
    • 1.8 Keywords to Frequent
  • 2. Comments
    • 2.1 Acceptable Formats
    • 2.2 Location and Content
  • 3. White Space
    • 3.1 Spaces
    • 3.2 Alignment
    • 3.3 Blank Lines
    • 3.4 Indentation
    • 3.5 Tabs
    • 3.6 Linefeeds
  • 4. Modules
    • 4.1 Naming Conventions
    • 4.2 Header Files
    • 4.3 Source Files
    • 4.4 File Templates
  • 5. Data Types
    • 5.1 Naming Conventions
    • 5.2 Fixed-Width Integers
    • 5.3 Signed Integers
    • 5.4 Floating Point
    • 5.5 Structures and Unions
  • 6. Procedures
    • 6.1 Naming Conventions
    • 6.2 Functions
    • 6.3 Function-Like Macros
    • 6.4 Tasks
    • 6.5 Interrupt Service Routines
  • 7. Variables
    • 7.1 Naming Conventions
    • 7.2 Initialization
  • 8. Expressions and Statements
    • 8.1 Variable Declarations
    • 8.2 If-Else Statements
    • 8.3 Switch Statements
    • 8.4 Loops
    • 8.5 Unconditional Jumps
    • 8.6 Equivalence Tests
  • Bibliography
  • Appendix A: Header File Template
  • Appendix B: Source File Template
  • Appendix C: Common Abbreviations

Guiding Principles (excerpt)

This coding standard was developed in accordance with the following guiding principles, which served to focus the authors' attention and eliminate conflict over items that are sometimes viewed by programmers as personal stylistic preferences:

  • Individual programmers do not own the software they write. All software development is work for hire for an employer or a client and, thus, the end product should be constructed in a workmanlike manner.
  • It is cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. A key strategy in this fight is to write code in which the compiler, linker, or a static analysis tool can detect bugs automatically&em;i.e., before the code is allowed to execute.
  • For better or worse (well, mostly worse), the ISO "standard" C programming language allows for a significant amount of variability in the decisions made by compiler implementers. These many so-called "implementation-defined", "unspecified", and "undefined" behaviors, along with "locale-specific options", mean that programs compiled from identical C source code may behave very differently at run-time. Such gray areas in the language standard greatly reduce the portability of C programs that are not carefully crafted.
  • This coding standard prioritizes code reliability and portability above execution efficiency or programmer convenience.
  • There are many sources of bugs in software programs. The original programmer creates some bugs. Other bugs result from misunderstandings by those who later maintain, extend, port, and/or reuse the code.
    • The number and severity of bugs introduced by the original programmer can be reduced through disciplined conformance with certain coding practices, such as the placement of constants on the left side of an equivalence (==) test.
    • The number and severity of bugs introduced by maintenance programmers can also be influenced by the original programmer. For example, appropriate use of portable fixed-width integer types (e.g., int32_t) ensures that no future port of the code will encounter an unexpected overflow.
    • The number and severity of bugs introduced by maintenance programmers can also be reduced through the disciplined use of consistent commenting and stylistic practices, so that everyone in an organization can more easily understand the meaning and proper use of variables, functions, and modules.
  • MISRA's Guidelines for the Use of the C Language are more restrictive than this coding standard--but worthy of study. Deviation from any MISRA-C required or advisory rule should be carefully considered. The authors of the MISRA-C guidelines are knowledgeable of the risks of the use of C in safety-critical systems. Our few known differences of opinion with [MISRA04] are identified in the footnotes to this standard. Followers of Barr Group's coding standard may wish to adopt the other rules of MISRA-C in addition to the rules found here.
  • To be effective, coding standards must be enforceable. Wherever two or more competing rules would be similarly able to prevent bugs but only one of those rules can be enforced automatically, this standard recommends the more enforceable rule.

In the absence of a needed rule or a conflict between rules, the spirit of the above principles should be applied to guide the decision.

Bug-Killing Coding Rules (article)

You can find examples of the kinds of bug-killing embedded C coding standard rules we follow in Michael Barr's April 2009 and May 2009 columns in Embedded Systems Design magazine as well as from time to time in his blog at http://www.embeddedgurus.net/barr-code.

How to Buy

The Embedded C Coding Standard book is available for purchase directly from Barr Group by e-mail (PDF) or mail (price includes shipping). Use the "Buy Now" button above to order your copy. Or you can order the print edition from a book retailer, including Amazon. Or order our Embedded Software Training in a Box, which includes a PDF copy.

Contact us to enquire about pricing for volume print orders, site licenses, and/or editable source documents (Word DOC format).

Comments

We implement embedded systems for process control and communication for our products. We have purchased and implemented the Embedded C Coding Standard book and it is fantastic. Following this standard has assisted us in eliminating bugs, running better code reviews, and increasing code portability.

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. -- Michael Koepp at Amazon.com

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.

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.

-- Rob Wehrli (excerpt) at Amazon.com

I recently purchased the "Embedded C Coding Standard" from Barr Group. We implement embedded systems for process control and communications for our products. The book is fantastic and we are moving to follow its rules ASAP.

The example on page 63 indicates that the else clause is taken when the expression is evaluated. When using gcc with std=c89 or std=c99, both will enter the if clause.

Looking at the C89/C99 standard, the integer promotion rules are applied. (Integer types smaller than int are promoted when an operation is performed on them. If all values of the original type can be represented as an int, the value of the smaller type is converted to an int; otherwise, it is converted to an unsigned int)

@Michael: is this correct?