Glossary

Find definitions for technical terms in our Embedded Systems Glossary.

A B C D E
F G H I J
K L M N O
P Q R S T
U V W X Y
Z Symbols

Test Your Skills

How good are your embedded programming skills? Test yourself in the Embedded C Quiz or the Embedded C++ Quiz.

Test Your Skills

Newsletter Signup

Want to receive free how-to articles and industry news as well as announcements of free webinars and other training courses by e-mail? Signup now.

Barr Group's Embedded C Coding Standard

ISBN 1-4421-6482-4
ISBN 1-4421-6482-4

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 e-mail (PDF) or mail (price includes U.S. shipping); simply make your selection and press the "Add to Cart" button to the right to order your copy now.

Table of Contents

  • 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 by e-mail (PDF) or mail (prices include shipping). To order, simply select the PDF or shipping type above and then click the "Add to Cart" button to begin the checkout process. PDF orders are available for digital download as soon as checkout is completed.

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