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&em;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. Amazon, and as an e-book on Kindle, Nook, and iBooks.

Table of Contents

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)

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. Kindle, Nook, and iBooks. --> 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).