Reason behind MISRA rule 111 - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Reason behind MISRA rule 111
Hi Chris,

Quoted text here. Click to load it

Because the rule checker ADDS VALUE.  It automates what would
otherwise be a manual process of inspecting code for compliance
with this set of rules and, presumably, *commenting* on the
results it discovers to *educate* the user (to the point where
the user will ultimately not need the checker, at all!)

Re: Reason behind MISRA rule 111
Hi David,

Quoted text here. Click to load it

As I mention elsewhere, recall that we aren't talking about
a "Standard" for interoperability, here.  It's not like needing
to come to concensus about how to enumerate a USB device, etc!

The "value added", in this particular case, is someone sat down and
codified a set of rules (most of which are obvious to a student
in a formal language course) regarding what you should *avoid*
when writing code.  [note that this is less severe than saying
you *must* avoid -- as MISRA does in many cases]

Spend an evening searching for "C coding standards" and you'll find
at least a dozen that address the same sorts of issues.  And none
of those web sites will require a PayPal account to access the

If MISRA wants to try to elevate their status to something
comparable to ISO 9000 certification, they need to add far more
value than "codifying the obvious".  (and, they'll have to be
able to defend their claims more aggressively to gain that
level of acceptance -- like DoD's Ada)

Quoted text here. Click to load it

What are the *costs* associated with it?  Besides "order takers",
what ongoing costs can they claim?  "Certification costs"??  Pass
those on to the vendors being certified (so that the vendor can
make an economic decision as to the *value* of that certification).
Charging to distribute a PDF is just silly.  It suggests that
they can't command a high enough premium from *vendors* to
cover their overhead (which implies that vendors don't consider
it worthwhile).

I wonder how widespread PDF's would be if every *reader* had
to be *purchased* from Adobe?  (yet, obviously they fare well
enough charging for *writers*!)

Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

They don't

\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

You don't have to comply to the MISRA rules to be MISRA compliant. You
just have to get the manager/product owner/whoever to sign a paper
explaining when and why you choose not to comply. This is the real

Instead of engineers making design and implementation decisions, managers
are by MISRA invited to make (or not make) them.

Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

This is only a problem if the managers or programmers don't fully
understand what they are doing. After 4 decades I have yet to be
convinced that either group knows what it is doing any better than the

\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

MISRA sort of claims to be able to mitigate that state of things.

Quoted text here. Click to load it

So what's the use to shift responsibilities between these groups?

I once worked with the MISRA rules. The company (automotive
subcontractor) applied MISRA thusly:

- All "advisory" rules were made "required".
- All rules, advisory or required, which couldn't be checked with a
static code checker were completely ignored. The instructions for code
review didn't and shouldn't contain them.
- While "break" and "continue" continued to be banned for no good reason,
"goto" was allowed. It was allowed only to jump to the only return
statement in a function, but how should the static code checker know
that, and as for code review, see above.

Apparently the customer (automotive OEM) was satisfied with this
"compliance" to MISRA.

Fredrik Ă–stman

Re: Reason behind MISRA rule 111
Hi Fredrik,

Quoted text here. Click to load it

Sheesh!  So what value does "MISRA compliance" have to *me*, a
"concerned third party"?  Does the manager have to be capable of
entering into a contractual relationship on behalf of the company
(i.e., legally obligating them)?  Or, is he just "speaking for
himself"?  (if the latter, does his *replacement* have to come in
and immediately re-certify these claims so *he's* "on-the-hook"
for past performance?)

Quoted text here. Click to load it

And we all know that managers are *the* go-to people when it comes to
knowing the latest technology, best practices, etc. -- since they spend
*so* much of their time keeping up with these things in a "hands-on"
manner.  (sarcasm)

(beating a dead horse)  Invest in your staff.  You can't *impose*
quality, reliability, etc. from "outside".  People have to feel
motivated, empowered and *safe* to build quality *into* any
product.  Otherwise, they just seek to cover-their-*sses so
they can't *technically* be held responsible for failures
(and, with the relative dearth of formal specifications, this
is *really* easy to do!  there's no "contract" for the design!)

On one of my first jobs, I supervised the build for a piece of
military avionics kit for a subcontractor.  There were lots of
problems with the documentation (since the serial numbers are
single digits, this is not uncommon).  Things were always getting
held up on the line as the device, as documented, couldn't be built!

When I was given the job, I didn't know *squat* about the actual
design ("subcontractor").  But, I would listen to folks on the line
explain their problems (with the drawing set), *ask* their opinions
as to what *they* thought the "right answer" should be, then, weigh
their answer against my "engineering knowledge" (sure, it may be
easier to change that #6 screw to a #4 so that it would fit in the
#4 tapped hole, but the *right* answer might be to redrill and
retap the hole for a #6!) and make an "executive decision" on the
spot -- mark up the print, initial it and get things rolling again.

Thereafter, folks were almost *happy* to bring things to my attention
even if they weren't "deal breakers":
   "You know, Don, these cables really shouldn't be routed over here
   as they are likely to be chafed by these unfinished edges.  (sparks
   are a Bad Thing on the flight line! :> )  We could either reroute
   the cables *or* add a finishing step to the metalwork in this area.
   What do you think?"
No longer were they worried about covering their backsides but,
rather, now eager to improve the product they were being paid to
build.  I had shown respect for their abilities (they work with this
stuff every day!) *and* was willing to put *my* neck on the line
(if the aircraft exploded, it was my initials on the print set).

When I subcontract work out to other folks, I don't want to have
to micromanage how they do that work.  If I don't trust your
abilities and work ethic, then why would I bother working *with*

[reread that as if it was a corporation speaking... why hire people
that you don't *implicitly* have faith in?  why not invest in them
to ensure they *remain* at the top of their game?]

Re: Reason behind MISRA rule 111

Quoted text here. Click to load it

You have just made good arguments for design standards.
misra is one such standard. Use it or not as you see fit. It
is low cost and written by people who have spent the time to
understand why some code is far more reliable than others and
translated the form that can be used as implementation guidelines.


Re: Reason behind MISRA rule 111
Hi Walter,

Quoted text here. Click to load it

You're missing the distinction I am trying to make.
"Standards" imply *rules*.  This takes the decision making
ability away from the person best qualified to make them
FOR THIS APPLICATION and forces a prescribed format on the
result -- that may or may not be appropriate.

I am all for *guidelines*.  I love running compilers with
all warnings enabled -- what can it suggest to me about the
code I've just written.  *BUT*, I can chose to ignore any
or all of those warnings as I see fit.

Standards turn what could be "warnings" into "errors"
that are artificially imposed.

"No, I *really* REALLY want to use a 'goto' here.  Yes, I
know why its use is discouraged.  But, I also know it was
included in the language for a *reason*."

I've been porting a design I wrote in Limbo *back* to C.
It is *so* much easier to do things in C without Limbo
trying to protect me from doing things that *might* be
risky.  The code reads a lot cleaner and runs a lot
faster (though that could just be a consequence of Limbo's

Sure, some things are a bit more work -- all the RPC's,
setting up secure tunnels, etc.  But, for the most part,
those are problems that can be solved once and "inherited"

Quoted text here. Click to load it

So, what does it buy me that any number of other *guidelines*
(not "standards") or books don't?  Why adopt (and conform)
to something that someone else is controlling?

Take the list of rules, white out the M, I, S, R and A at
the top of the page -- along with anything else that you
disagree with -- write your own initials there, instead,
and treat them as GUIDELINES not REQUIREMENTS.

Re: Reason behind MISRA rule 111

Quoted text here. Click to load it

The main reason is the misra group are in the business of developing
standards and not software. There are some very good software
developers whose business model is to implement standards including
checking misra rules.


Re: Reason behind MISRA rule 111
Hi Walter,

Quoted text here. Click to load it

If a customer wants me to design a set of guidelines (for
coding style, testing, etc.) then I charge them for the

[I *really* don't like this sort of task because you "can't win":
the sorts of clients that want to develop these guidelines tend to
be small shops suffering "growing pains".  They invariably want
*rules* that they can forget about (hire a policeman). And, you
*know* that those "rules" will be resented by the folks they are
imposed upon.  And, *you* (I) will be the personification of that

I don't tell them, "before I start this coding project for you,
I need to charge you to develop a set of guidelines that will apply
to that code -- its design, documentation and testing".  They benefit
from the guidelines that I've evolved over the past few decades.

[I've had several clients amused by how "consistent" my designs
are -- whether hardware or software.  My ASICs look like they
were designed "mechanically"!]

They pay for that in terms of my level of experience.  They benefit
by being exposed to those code samples and my exchanges with their
staff.  I, in turn, learn from them -- the particulars of their
application domain, any hardware or software "tricks" that I
develop while working on their project, etc.

I'm not getting paid to share my beliefs *here*.  I'm not trying
to be coy saying, "Buy *my* 'standard' instead".  Rather, I am
putting forth the argument (for *free*) that "Standards" (in the
sense we are discussing here) have big downsides when treated as
legislation instead of recommendation.

Anyone who's spent more than a minute around the watercooler
arguing/pondering/complaining about some unilaterally imposed
"coding rule" represents a hidden cost of that "standard's
enforcement".  If you listen to the folks in shops that have
these sorts of things *imposed* vs. taking control of their
*own* "guidelines", you will see a big difference in their
attitudes towards their work and their employer.

Invest in your staff so that they are better able to *make*
these decisions intelligently instead of imposing "rules"

Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

If you are unable to work to customer specifications and guidelines you
seem unemployable.

\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Reason behind MISRA rule 111
Quoted text here. Click to load it

Why do you insist on trying to provoke me with ad hominem attacks?

Please *cite* where I stated that *I* am "unable to work to customer
specifications and guidelines"?  My parse (and intent) in the above
seems very clear:
     "If a customer wants me to DESIGN A SET OF GUIDELINES then I
     charge them for the work I do towards that goal" (i.e., "If I am
     hired for the express purpose of designing a set of guidelines,
     then I charge them TO DESIGN THAT SET OF GUIDELINES").
This implies:
-- the customer doesn't have (or isn't happy with) suitable guidelines;
-- I am employable (because the customer hired me);
-- and that I am expected to be competent to perform this task
    within whatever "specifications and guidelines" are set forth
    for its performance.

As I;ve said (elsewhere?), I don't like this sort of task because
it's a no-win scenario.  I can, instead, provide a list of books
that he/his staff might want to review or point them to other
published guidelines, etc.

In every case, my *recommendation* is the same:  invest in your
people (if you don't believe in their abilities, then why did you
hire them?)

Site Timeline