My book Embedded C Coding Standard began as an internal coding standard of a consulting company and was first published in 2008 by that company (Netrino). In 2013, the book’s cover was given a new look and the standard became known as “Barr Group‘s Embedded C Coding Standard“. A 2018 update to the book will be released soon and this will be the first time the substance of the standard has changed in over a decade.
The primary motivation for making changes is to better harmonize the rules with the MISRA-C Guidelines. The older Barr Group standard made reference to MISRA C:2004, which was superseded by MISRA C:2012. The few known direct conflicts between BARR-C:2013 and MISRA C (stemming from our earlier embrace of ISO C99) were effectively eliminated with their 2012 update. But we wanted to do more than just remove those noted conflicts and push even further in our embrace of harmonization.
In a sentence, MISRA C is a safer subset of the C language plus a set guidelines for using what is left of the language more safely. In about as many words, BARR-C is a style guide for the C language that reduces the number of defects introduced during the coding phase by increasing readability and portability. It turns out there is quite a bit of value in combining rules from both standards. For example, MISRA’s guidelines do not provide stylistic advice and applying BARR-C’s stylistic rules to the C subset further increases safety.
The rest of this post is a preview of the specific rule changes and additions we will make in BARR-C:2013. (Omitted from this list are rules reworded simply for greater clarity.)
Rule 1.1.d (new)
The following rule will be added:
Preprocessor directive #define shall not be used to alter or rename any keyword or other aspect of the programming language.
Rule 1.6.b (new)
The following rule will be added:
Conversion from a pointer to void to a pointer to another type shall be cast.
Rule 1.7.c (change)
The earlier rule:
The goto keyword shall not be used.
will be replaced with:
It is a preferred practice to avoid all use of the goto keyword. If goto is used it shall only jump to a label declared later and in the same or an enclosing block.
This is being done so that the BARR-C standard does not restrict uses of goto that are permissible under MISRA C.
Rule 1.7.d (change)
The earlier rule:
The continue keyword shall not be used.
will be replaced with:
It is a preferred practice to avoid all use of the continue keyword.
This is being done so that the BARR-C standard does not restrict uses of continue that are permissible under MISRA C.
Rule 1.7.e (eliminated)
There will no longer be any restriction on the use of the break keyword. This is being done so that the BARR-C standard does not restrict uses of break that are permissible under MISRA C.
Rule 4.2.d (change)
The earlier rule:
No header file shall contain a #include statement.
will be replaced with:
No public header file shall contain a #include of any private header file.
This is being done because apparently no one (other than me) actually valued the old rule. 
Rule 5.1.c (new)
The following rule will be added:
The name of all public data types shall be prefixed with their module name and an underscore.
Rule 5.4.b.v (new)
The following rule will be added:
Always invoke the isfinite() macro to check that prior calculations have resulted in neither infinity nor NaN.
Rule 5.6.a (new)
The following rule will be added:
Boolean variables shall be declared as type bool.
Rule 5.6.b (new)
The following rule will be added:
Non-Boolean values shall be converted to Boolean via use of relational operators (e.g.,
Rule 6.2.c (changed)
The earlier rule:
All functions shall have just one exit point and it shall be at the bottom of the function. That is, the keyword return shall appear a maximum of once.
will be replaced with:
It is a preferred practice that all functions shall have just one exit point and it shall be via a return at the bottom of the function.
Rule 6.3.b.iv (new)
The following rule will be added:
Never include a transfer of control (e.g., return keyword).
Rule 7.1.n (new)
The following rule will be added:
The names of all variables representing non-pointer handles for objects, e.g., file handles, shall begin with the letter ‘h’.
Rule 7.1.o (new)
The following rule will be added:
In the case of a variable name requiring multiple of the above prefixes, the order of their inclusion before the first underscore shall be [g][p|pp][b|h].
Rule 7.2.c (new)
The following rule will be added:
If project- or file-global variables are used, their definitions shall be grouped together and placed at the top of a source code file.
Rule 7.2.d (new)
The following rule will be added:
Any pointer variable lacking an initial address shall be initialized to NULL.
Rule 8.2.a (changed)
The earlier rule:
The shortest (measured in lines of code) of the if and else if clauses should be placed first.
will be replaced with:
It is a preferred practice that the shortest (measured in lines of code) of the if and else if clauses should be placed first.
Rule 8.3.c (new)
The following rule will be added:
Any case designed to fall through to the next shall be commented to clearly explain the absence of the corresponding break.
Rule 8.5.b (new)
The following rule will be added:
The C Standard Library functions abort(), exit(), and setjmp()/longjmp() shall not be used.
If you have questions about any of these draft changes or suggestions for better or other changes, please comment below.
