Selecting Guidelines : MISRA 1998 or MISRA 2004 or MISRA 2012?

Question

I always wondered how does a project/team/company selects or qualifies for choosing a specific guideline to be followed like MISRA 1998/2004/2012? How should one know and decide that which guideline will be sufficient (cost vs time vs quality) for qualifying a project?

(I know his question is a bit blunt, but any answers will be appreciated)

Answer 1

Just as with your compiler suite or development environment, and/or your static analysis tools, the appropriate version should be decided at the on-set of a project, as it may be difficult to change later!

If you are starting a project from scratch, then I would recommend that MISRA C:2012 is adopted - while also adopting the guidance of (published April 2016, revised February 2020) MISRA Compliance

The new Compliance guidance also offers advice on how to treat Adopted Code (ie pre-existing or imported code).

Existing projects that have been developed to earlier versions should continue to use that earlier version... unless there is a good business case for changing. Changing WILL result in some rework!

Answer 2

Code shall be written such that it has certain desired properties (quality criteria). Some quality criteria are practically always desired, like correctness, readability, maintainability (even here are exeptions, for example if you code for the obfuscated c contest or underhanded c contest). Other quality criteria are only relevant for certain projects or organizations, for example portability to 16 bit machines.

A well formulated coding rule typically supports one or several quality criteria. It can, however, be in conflict with others. There is a large number of established coding rules that support the typically desired quality criteria, but without significant negative impact on others. Many of these have been identified quite a long time ago (Kernighan and Plauger: Elements of Programming Style, 1974, and, yes, I have a copy of it :-). At times additional good rules are identified.

Unless in very rare circumstances (like, intentional obfuscation) code should follow these "established good rules", irrelevant of whether they are part of MISRA-XXXX or not. And, if a new good rule is found, ensure people start following it. You may even decide to apply this new good rule to already existing code, but that is more of a management decision because of the risk involved.

It simply does not make sense not to follow a good rule just because it is not part of MISRA-XXXX. Similarly, it does not make sense to follow a bad rule just because it is part of MISRA-XXXX. (In MISRA-C-2004 it is said they have removed 16 rules from MISRA-1998 because "they did not make sense" - hopefully some developers have noticed and did not apply them. And, as Lundin mentions, in MISRA-2012 again some "weird rules" have been removed).

However, be aware that, for almost every rule, its thoughtless application can in certain situations even degrade those quality criteria which it normally supports.

In addition to those generally applicable rules, there are rules that are only relevant if there are specific quality criteria for your code. What complicates things is that, in most projects, for different parts of the code the various quality criteria are of different relevance.

• For an interrupt service routine performance is more critical than for most other parts of the software. Therefore, compromises wrt. other quality criteria will be made.
• Some software parts are designed to be portable between environments, but often by introducing adapters/wrappers which are then specific for a certain environment. Thus, the adapter itself is not even intended to be portable.

Except for the abovementioned "established good rules", a fixed set of coding rules consequently can not work well for all parts of a typical software. So, for each part of the software first identify which quality criteria are relevant for that part. Then, apply those patterns, principles and rules which really support those specific quality criteria appropriately.

But, what about MISRA? The MISRA rules are intended to support quality criteria like correctness via analysability (e.g. ban of recursion and dynamic memory management), portability (e.g. isolation of assembly code). That is, for software parts where these specific quality criteria are not relevant, the respective MISRA rules do not bring any benefit. Unfortunately, MISRA has no notion of software architecture, where different parts have different quality criteria.

While many rules have improved over the MISRA releases, there are still many rules that are stricter than necessary (e.g. "no /* within // comments and vice versa" - why?) and rules that try to avoid (unlikely) mistakes in ways that are likely to introduce problems rather than solving them (e.g. "no re-use of any name, not even in different local scopes"). Here's my tip for you: If you a) really want your rule-checker to find all bugs and b) don't mind getting an absurd amount of warnings with a high false-positive ratio, this one rule/checker does it all for you: "warning: line of code detected: <line of code>".

Finally, MISRA is developed under the assumption that C (in particular its arithmetics) are too hard to understand. MISRA developes its own arithmetics on top of C in the belief that developers instead should learn the MISRA arithmetics and then can get away without understanding C arithmetics. Apparently, this has not been successfull, because the MISRA-2004 model ("underlying type") was replaced by another one ("essential type") in MISRA-2012. Thus, if your team understands C well and uses a good static analysis tool (or even several) which is capable of identifying the problematic scenarios with C's arithmetics, the MISRA approach is likely not for you.

TL;DR: Follow standard best practices, apply established good rules. Identify specific quality criteria for the different parts of your architecture. For each part, apply patterns, principles and rules appropriate for that part. Understand rules before applying them. Don't apply stupid rules. Use good static code analysis. Be sure your team understands C.

Answer 3

This is often a requirement from the area of application. You'll have safety standards dictating that a safe subset of the programming language is used. This requirement can come from the "SIL" standards such as industry IEC 61508, automotive IEC 26262, aerospace DO-178 and so on. In such mission critical systems, you may not have any other choice than to use MISRA-C.

But MISRA-C is also becoming industry standard for all embedded systems, no matter their nature. The reason why is obvious: nobody, no matter area of application, likes bad, low-quality software full of bugs.

Introducing MISRA-C, together with company coding guidelines, style rules, static analysis, version control... all of it will improve the quality of the end product significantly. And it will force the programmers to educate themselves about C, while becoming more professional overall.

That being said, MISRA-C is not necessarily the most suitable set of rules for every company. It is mostly applicable to embedded systems. For other kinds of applications, something like CERT-C might be more relevant. It is convenient to use one of these well-known standards, because then you can automate tests with static analysers.

They key here is that every semi-professional company that produces software needs some sort of coding rules that focus on banning bad practice. Some companies tend to focus way too much on mostly unimportant style details like where to place {, when they should focus on things that truly improves software quality, like "we should avoid writing function-like macros".

The coding rules should be integrated with development routines. It doesn't make much sense to implement MISRA-C for one single project. There is quite a lot of work involved in getting it up and running.

What is very important is that you have at least one, preferably several C veterans with many years of experience, that you put in charge of the coding rules. They need to read every dirty detail of the MISRA document and decide which rules that make sense for the company to implement. Some of the rules are far from trivial to understand. Not all of them make sense in every situation. If your dev team consists solely of beginners or intermediately experiences programmers and you decide to follow MISRA to the letter, it will end badly. You need at least one veteran programmer with enough knowledge to make the calls about which rules to follow and which to deviate from.

As for which version of MISRA-C to pick, always use the latest one: 2012. It has been cleaned up quite a bit and some weird rules have been removed. It also supports C99, unlike the older ones.