Embedded Curmudgeon Column MTE April 2013 Call that a Coding standard? By Chris Hills

 

For those of you who remember PJP’s columns in Byte Magazine, (You DO remember Byte Magazine, don’t you?) I am in the beach-garden of a hotel overlooking the Indian Ocean using my tech-work laptop and my second favourite word processor during a break in a business meeting. I only mention this as it is 25-30c here and there is snow at home in the UK.

Coding standards: There are a lot of them about. CertC, JSF, Netrino’s, MISRA et al. And MISRA-C:2012 is due any day now. C3, to its friends, is a major revision, which I will discuss in a moment.

A recent survey discovered is MISRA-C is the most widely used coding standard: 15% of companies surveyed are using it. The majority of companies, some 35%, use in-house standards, many of which use MISRA-C as a major reference. So probably more than 50% of those companies using coding standards for C use MISRA-C in some form. As I wrote in June 1998, when looking at the first MISRA-C, it works with any embedded C system - be it automotive, medical, nuclear, aerospace, communications or even consumer systems. Indeed it has spread into all those areas and the largest single group on the MISRA-C:2012 team is working in defence/aerospace.

A coding standard should help you to avoid shooting yourself in the foot. It should help you avoid, in the words of Dennis Richie, “legal but dubious constructs“! From the trivial, like putting a long into a char to subtle errors in the complex use of pointer arithmetic or mixing signed and unsigned without thought. (And don’t mention using void return type to contain data.) These are things that will inevitably conspire to cause behaviour you don’t want and that will take time, resources and in all cases costing money. Time and resource always cost someone money.

JUST BECAUSE IT COMPILES DOES NOT MEAN IT IS CORRECT! Despite this, the survey also concluded that some 30% of companies still don’t use any formal coding standard! Perhaps these companies have time and money to spare? Perhaps they like to spend time debugging.

There is a lot of confusion about coding standards: one area of confusion is the difference between a coding standard and a style guide, another is what should actually go into a coding standard. Also there are questions about how and where you enforce a coding standard. Most companies combine style and coding standards in one document, which is a good idea. Style is about uniform readability and it has no direct effect on what you can do with the language: however if all the code is laid out in a uniform way it is far easier to see the problems and it helps the mind focus on the functionality.

There is no right or wrong way of doing style: which is why MISRA-C does NOT have any style rules. Remember since the initial K&R C (and I mean K&R1 not K&R2), some 35 years ago, things have moved on, both the understanding of style and the language itself (C90, C95, C99 and C11). Programmers should focus on functionality and not on the style! Just use the house style: the “art” in software is the design, functionality and algorithms and not where you put the { or how many spaces there are in a tab. If you get hung up on layout details, you are focusing on the wrong thing. Use the style guide you are given and get on with it so that there is only one style for the company.

The next thing is, “What should go into a coding standard?” This is also coupled with where and how to you enforce it? We now enter a minefield. MISRA-C1 was wonderful, short, concise and “everyone” knew what it meant. This was until the static analysis tool vendors got involved. They quickly found that while “everyone” did know what it meant, they all had different answers. The tool companies needed a single universal unambiguous answer. MISRA-C2 (2004) was said by some to be MISRA-C for tool companies because we removed many of the ambiguities. For MISRA-C2 when it was something “everyone knew”, most of the time most of the people had the same answer. For MISRA-C3 this has, we hope, been improved again. This is a problem with all coding standards: how to make them precise, accurate and readable to the point where everyone has the same understanding of the problem and of the solution.
Also as a sanity check in development of C3, we expanded the rational and examples. Now it is much easier to see why the rule is there and what it is trying to achieve. So whilst C3 is larger than C2, there are only a few more rules.

So the tool vendors are happier as they can implement the rules with less ambiguity. That said not all the rules are *statically* enforceable. Some are “documentation” rules - that is they require you to list things in your project documentation. This covers things like the restrictions and extensions on the C language that your compiler developer has chosen to implement, along with the handling of “unspecified” and “undefended” behaviours in C. While careful tuning of a static analyser will also catch these, some rules may be better tested in another tool. The way of sorting this out is to do a compliance Matrix. List all the rules in your coding standard along with where they are checked. Some might be checked in the compiler but most will be checked in the static analyser. Actually, MISRA-C, IEC 60158 and derived standards etc requires the use of static analysis, as the only way of checking the additions and restrictions to C is with a properly configured static analyser. (And there are all the other benefits of static analysis.)

There are other rules you may want in a coding standard and again these may not be enforceable in a static analyser. For example, you might (should) want standard information blocks on source files and function definitions. These are easy to do, especially if you use a version control system (VCS) that supports keywords. This will automatically insert things like file name, author, file location, and maintain the full change log. The tip here is that one person should set up the templates, mark them as “read only” and then copy them to all the other team members. The same procedure should be used with the IDE/Editor set up file for function templates and things like the number of spaces in the tabs. This ensures consistency as they can’t be edited locally.

The more you can control and test automatically the better. Use the features of the VCS system, the features of the compiler IDE and static analysis. Ask why every rule is in the coding standard and identify what it is trying to do? Also if you use a readymade coding standard, or use one as a base for a local one, look at where it comes from. What is the experience and background(s) of the authors? We worked out that the MISRA-C team has over 200 years’ experience, most of it looking at high-reliability systems across a wide range of industries.

Just because it compiles does not mean it is right:  always set the compiler warning level to max and fix ALL errors and warnings. No matter how theoretically good the source is after static analysis, if the compiler has a problem translating the source to binary you have a question mark over the binary. It is the binary not the source that drives the MCU.

 

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2013
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988

 

 

> EC Index