MISRA C: What About Coding Style?
Style, while being essential to ensure program readability, is highly subjective. Everyone in software development knows that matters apparently as futile as the positioning of opening and closing braces can cause friction within the development team. Nonetheless, as observed in BARR-C-2018,
"[...] programmers do not own the software they write. All software development is work for hire for an employer or a client [...]"
So someone has to make stylistic choices and consistency is usually much more important than the exact details of the chosen rules. MISRA C leaves all stylistic matters to the judgment of the individual organization, but it clearly states that
"[...] It is recognized that a consistent style assists programmers in understanding code written by others. However, since style is a matter for individual organizations, MISRA C does not make any recommendations related purely to programming style. It is expected that local style guides will be developed and used as part of the software development process."
In this regard, MISRA C aligns with ISO 26262, which highly recommends the use of style guides for ASILs B, C and D. The importance of coding style to enhance readability is also remarked in IEC 61508, IEC 62304 and other standards. A readable program is a program where peer review is more effective. In turn, the combination of peer review and static analysis is well known to be the most efficient strategy for software defect removal (see C. Jones and O. Bonsignour, The Economics of Software Quality, 1st ed. Addison-Wesley Professional, 2011).
OK, We Need a Style Guide: Which One Should We Choose?
Four criteria speak for themselves:
- It must exist in written form.
- It must have a proven track record.
- It must not conflict with MISRA C.
- It must be supported by tools.
As far as we know, only BARR-C:2018, the Barr Group's Embedded C Coding Standard, satisfies all four criteria. Among the 143 guidelines of BARR-C:2018, 79 are stylistic in nature. They cover guidance on line width, horizontal spacing (blank space, tabs, alignment, indentation), vertical spacing (new-line and other control characters), further code layout issues, naming (modules and files, types, functions, variables), language, comments, and source file contents. BARR-C:2018, which can be downloaded free of charge from http://www.barrgroup.com/, has been widely adopted starting from its first edition, the 2009 Netrino's Embedded C Coding Standard. This was then followed by BARR-C:2013. BARR-C:2018 has evolved from the 2013 edition with the objective of avoiding any conflict with MISRA C:2012. And tools? Keep on reading.
ECLAIR Support for BARR-C:2018
ECLAIR has always supported Barr's coding standards, Netrino C:2009, then BARR-C:2013 and now BARR-C:2018. Pick up any contemporary ECLAIR package and you will discover that it contains support for all statically checkable guidelines of BARR-C:2018, including, in particular, those concerning coding style. Indeed, for projects without strict MISRA C requirements, we recommend BARR-C:2018 also for the language subsetting guidelines.
What if I Start with an Existing Codebase?
The forthcoming release, ECLAIR 3.12.0, comes with an exciting new feature for those who accept our advice of embracing BARR-C:2018. The new eclair_format program (shipped with all ECLAIR packages) automatically formats existing source code to comply with the stylistic guidelines of BARR-C:2018. It can be used as a giant time-saver at the beginning of the transition to BARR-C:2018. Once that is done, development can continue following the new style and ECLAIR will flag any newly introduced deviation.
ECLAIR 3.12.0 will be available soon. In the meantime, book a free guided tour with our technical team to get a preview and evaluate what’s coming without having to download and install anything.
Don't forget to join our LinkedIn community to keep up to date with all our news.