Michael Barr releases embedded C coding standards

Every C programmer has ideas about writing better C code. Comment first, agile, use this compiler etc.

The Barr Group recently released a coding standards guideline for embedded C, which is also available as a freely downloadable ebook. The guidelines are grouped rules that fall under 8 broad categories (general, comments, white space, module, data type, procedure, variable and statements).

Michael Barr is the CTO and co-founder of Barr Group. He has a Masters in electrical engineering, was an adjunct professor in electrical engineering/computer science and founded a company called Netrino and the Barr group for embedded systems consulting. He was also the Editor-in-Chief of the Embedded Systems Programming magazine. He has decades of experience so this should prove to be a great reference guide.

What are these C guidelines about?

C is pretty open-ended and leaves a lot of space of misuse. That is, a lot of bad code can be written in C. Any programming language can’t really prevent bad code, people have different approaches, some less efficient than the others.

In the guidelines, Barr lists ways to change habits while coding. He states in his guideline book “The reliability, readability, efficiency, and sometimes portability of source code is more important than programmer convenience.”

His also talks about MISRA C, the 20-year-old guideline created to promote more reliable programming. MISRA still is the gold standard for many embedded programmers. But MISRA avoids many issues of style, indentation, naming conventions, casings, and so on. But Barr does not shy away from any of that.

It’s good to follow rules

It isn’t uncommon for programmers to overlook the simple stuff. For example, they don’t bother with using braces for simple statements just because the language allows you to do so.

Rule 1.3 states that all blocks however trivial should be enclosed in braces. The reasoning is “There is considerable risk associated with the presence of empty statements and single statements that are not surrounded by braces. Code constructs like this are often associated with bugs when nearby code is changed or commented out. This risk is entirely eliminated by the consistent use of braces. The placement of the left brace on the following line allows for easy visual checking for the corresponding right brace.”

The employer owns the software/code you write. The employer would naturally expect you to follow the best known industry standards for the code to be least buggy and maintainable as possible. In addition, the C language is also not standard throughout, different compilers can produce different runtimes from the same code. This happens even if your code is clean and adhering to all ISO standards.

Write legible code

The code you write will most likely be used in the future. A short but dense code block can make you feel clever but will lack legibility. We are way past the times to bother about extra lines of code or comments taking up floppy disk space. Write for readability, comment generously, indent your loops and compound statements.

Many seasoned programmers may already know or practice many of the rules stated in the book. But nonetheless it can serve as a really good reference guide for beginners and veterans alike. There are eight sections of rules with subsections in them.

These were just some of the ideas presented in the guidelines, you can get the free PDF download or and if your prefer, the paperback version is available on Amazon.

The 5 most popular programming languages in 2018

Polymorphism and type-pattern matching in Python [Tutorial]

Qml.Net: A new C# library for cross-platform .NET GUI development