MISRA rules that don’t make sense

on May 13, 10 • by Alen Zukich • with 3 Comments

Previously I posted the value of using coding standards, specifically MISRA C and MISRA C++.  This time I wanted to go through some general experiences we had with some of the checkers, specifically the ones that seem to throw a lot of violated rules, to the point that on some code bases MISRA flagged more ...

Home » Software Compliance » MISRA rules that don’t make sense

Previously I posted the value of using coding standards, specifically MISRA C and MISRA C++.  This time I wanted to go through some general experiences we had with some of the checkers, specifically the ones that seem to throw a lot of violated rules, to the point that on some code bases MISRA flagged more than one error per LOC!

There are still tons of great rules you can apply even if you don’t make an embedded product.  But as I said before, it doesn’t make sense to turn on all the MISRA rules.  After running through many code bases and looking at the value of MISRA we certainly noticed a trend with a few culprits.  Here are a few examples that we found to be noisy with non-MISRA compliant code.

MISRA C 6.3 and MISRA C++ 3-9-2:

MISRA has the distinction of “required” rules and “advisory” rules.  This is an “advisory” rule.  Essentially it wants you to avoid using types like char, int, short, long etc. and to use specific length typedefs instead.  Obviously, many code bases use the basic types, so be prepared for many issues.

MISRA C 14.9 and MISRA C++ 6-4-1:

This is a “required” rule.  This rule  is really about making sure you have braces for your if/else keywords.  Good practice to have but how many of us really do this?

MISRA C 12.13 and MISRA C++ 5-2-10:

This is an “advisory” rule.  The rule doesn’t want you to mix increment and decrement operators into an expression.  This makes sense because it can be pretty confusing to read.  But in our experiments this seems to be something that many developers do.

MISRA C 17.4 and MISRA C++ 5-0-15:

This is a “required” rule.  The rule only wants to allow you to use array indexing for pointer arithmetic.  Everything else is non-compliant.

MISRA C 14.7 and MISRA C++ 6-6-5:

This is a “required” rule and another control flow example.  A function can only have one point of exit at the end of a function.  I can understand this but as you know, that is not reality.

MISRA C 13.2:

This is an “advisory” rule.  It states that tests against zero should be made explicit.  In other words: if (x != 0) is the proper way, not if (x).  The exception to this is if the operand is Boolean.  I don’t know about you, but you can crown me the super wiener on this? I never make it explicit.

So if you plan to pick up MISRA on your existing project beware of these rules.  I’d like to hear if you do any of those things in your code base.

Related Posts

3 Responses to MISRA rules that don’t make sense

  1. vlad says:

    If someone doesn’t use these rules doesn’t mean they have no sense. Reading/maintaining code compliant with MISRA is much easier.

  2. Mark says:

    6-6-5 – the checker we are using flags every function which doesn’t have an explict ‘return’ as the final statement. We’ve written functions for years, only using the ‘return’ statement when there was a value to be returned.

    6-4-2 – All if…else if constructs must be terminated with an else clause. I don’t see how adding unneeded else clauses, containing null statements is helpful. It leads to…

    6-2-3 – a null statement shall be on a line by itself. So you can’t add an endline comment explaining that you’re just trying satisfy 6-4-2.

    6-4-6 – final clause of switch statement shall be default. We often default to a “middle case”, e.g.,
    switch (color)
    {
    case red:
    stop();
    break;
    case yellow:
    default:
    caution();
    break;
    case green:
    go();
    break;
    }

  3. Erik says:

    > I’d like to hear if you do any of those things in your code base.

    I rarely use pointer arithmetic. Maybe in driver code when assigning registers. But that is it. As far as using !x instead of x != 0, I do that exclusively in C++. It just seems more readable to me. I would find 13.2 very annoying.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top