Q&A: What is Barr Group's Approach to Coding Standards?

Aug. 1, 2016
The Barr Group champions coding standards and safe software practices through guidance, advocacy, and training of embedded developers.
Download this article in .PDF format This file type includes high-resolution graphics and schematics when applicable.
Andrew Girson, Co-Founder and CEO, Barr Group

Electronic Design’s Bill Wong talked with the Barr Group’s Andrew Girson about how the organization champions coding standards and safe software practices through guidance, advocacy, and training of embedded developers.

Wong: What are the typical C coding standards in use?

Girson: There are quite a few coding standards out there. Our recent Safety and Security Survey results indicate that most companies utilizing a coding standard have developed their own proprietary standard. The most popular published standard according to survey results is the MISRA coding guidelines, although Barr Group’s coding standard and the coding standard based on the Linux kernel also have a following.

Wong: Why are there so many different coding standards and why are there so many exceptions in practice?

Girson: Organizations have different requirements and needs in terms of the software they develop. Stylistic opinions on the visual representation of code also vary among organizations and individuals within organizations. These factors are predominant in explaining why so many organizations create their own proprietary standard, even if they base it off of a published standard.

Regarding exceptions to coding standard rules, because stylistic opinion drives many coding standard decisions, disagreements will fuel exceptions. Also, in today’s embedded software world, most software code bases incorporate code from multiple organizations, and these organizations may utilize different (or no) coding standards. So, you get code bases that are founded on a variety of coding standards.

Wong: What is different about the Barr coding standard?

Girson: Organizations incorporate many philosophies and strategies into their coding standards. In our case, the primary decision-making in developing the Barr Group Embedded C Coding Standard is based on reliability and correctness. Where one choice on a coding standard rule would result in fewer bugs and higher reliability, that’s the rule we implement in our standard. Our coding standard also incorporates readability and portability as important aspects.

So, while many process factors are involved in creating reliable code, a coding standard plays an important role and the Barr Group Embedded C Coding Standard is specifically focused on keeping defects out of software in the first place.

Wong: What advantages are there to using a coding standard?

Girson: While we have already discussed reliability, portability, and readability as key advantages of using a coding standard, the concept of maintainability is extremely important. Most code bases live for years or even decades, and these code bases are likely to be maintained and updated by engineers who were not involved in the original development. Maintaining quality and reliability as code bases evolve requires a good understanding of the code, and that understanding starts with well-written and consistently styled code.

Wong: What options are there for automatically enforcing coding standards?

Girson: Many commercially available static-analysis software tools incorporate a means to enforce coding standards. And, many of these tools already have profiles for commonly utilized standards, such as the MISRA coding guidelines and Barr Group standards. Examples of companies that provide such tools include LDRA, Gimpel Software, GrammaTech, and Synopsys.

Wong: What is the percentage of developers who utilize automatic enforcement mechanisms?

Of approximately 2500 responses in Barr Group’s recent Embedded Safety

Girson: The results of Barr Group’s 2016 Embedded Software Safety & Security Survey indicate that the use of tools to automate enforcement of coding standards is lacking. Of approximately 2500 respondents, only about 50% actually utilized static-analysis tools in any way for their projects. Of those who followed a coding standard, just 23% partially automated and 7% fully automated enforcement of coding standard compliance with a tool like this (see figure).

For the subset of engineers developing embedded devices that could kill or injure the user if the device malfunctioned, the number of respondents that used static-analysis tools on their projects increased to about 84%. Would you want to be a user of one of those devices developed by the other 16% of respondents in this subset? I know I wouldn’t!

Wong: What recommendations do you have for using coding standards?

Girson: The primary recommendations are to use a standard and to enforce it through the use of static analysis. At Barr Group, our goal is to provide an objective voice in the embedded software community, and as such, we do not generally recommend one tool over another. The fact is that there are many coding standards and a number of tools available. Choose the ones that best suit your specific needs. And, even if a portion of your code base is from a third party that did not use a coding standard, it is no excuse for not utilizing a coding standard in your own code.

Be an advocate within your organization for the use of coding standards, static analysis, and peer code reviews. Your code will be better, your users will thank you, and your organization will reduce long-term liability and development costs.


Barr Group Embedded C Coding Standard

Barr Group Training Calendar: Upcoming Public Courses

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!