[weland]

In my experience, the major problem with standards like MISRA is that people read the rules, but rarely the rationale behind them, which makes every coding standard end up encouraging cargo cult bug avoidance.

Case in point: MISRA C forbids goto statements primarily because it can mess up static analysis. Yet this rule is gratuitously followed even when no static analysis tools are used, thus yielding none of the gains that you trade off for occasionally writing ugly code.

[christianbryant]

The intent with standards like MISRA C is actually to be a reference point against which certifiable audits can cite companies for infractions. That is, the standard is no good as you note, unless a desired industry certification is only attainable for a company if an audit demonstrates the programmers are indeed following the rules.

Otherwise, you're right. The value goes out the window without enforcement, without compliance.

[weland]

Absolutely. If you're audited for MISRA compliance, you need to follow it point by point.

The rules themselves are not meaningless or without a point, but there are a lot of companies that adopt MISRA without actually having (in the sense of audit and certification) to be compliant. Instead of focusing on the point of every provision, they rigidly follow them even when not applicable.

But it can be worse, really. The gem of a coding standard we have at $work forbids not only goto, but also break, without MISRA's exception of one break per loop. And forbidding the use of goto and continue is cited as being done for readability reasons, rather than static analysis tools.