Reason behind MISRA rule 111

In message <iqqvjm$qnc$2@news.albasani.net>, "Fredrik :Ostman"
<Fredrik.Oestman@invalid.invalid> writes
>>-----< D Yuniskis >
>> 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]
>
>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
>problem.
>
>Instead of engineers making design and implementation decisions, managers
>are by MISRA invited to make (or not make) them.

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
other.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 5/16/2011 3:50 AM, Chris H wrote:
> In message<iqqsv9$vcp$1@speranza.aioe.org>, D Yuniskis
> <not.going.to.be@seen.com>  writes
>> Hi Walter,
>>
>> On 5/15/2011 11:28 PM, Walter Banks wrote:
>>> D Yuniskis wrote:
>>>
>>>> *Personally*, I abhor "closed" and "for pay" standards -- if what
>>>> you have is so wonderful (and really little more than a piece of
>>>> electronic paper), why horde it?
>>>
>>> I assume that you don't charge for the work you do for customers.
>>
>> If a customer wants me to design a set of guidelines (for
>> coding style, testing, etc.) then I charge them for the
>> work I do TOWARDS THAT GOAL.
>
> If you are unable to work to customer specifications and guidelines you
> seem unemployable.

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?)

Hi Fredrik,

On 5/16/2011 3:51 AM, Fredrik :Ostman wrote:
>> -----<  D Yuniskis>
>> 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]
>
> 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
> problem.

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?)

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

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*
you??

[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?]

David Brown wrote:

> Maybe I'm naive here, and the sums wouldn't work out in the end.  But
> Misra charge �10 for their pdf - it's absurd.  Give it out free, and
> charge �100 for a Misra rule checker program.

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.

w..

D Yuniskis wrote:

> Hi Fredrik,
>
> On 5/16/2011 3:51 AM, Fredrik :Ostman wrote:
> >> -----<  D Yuniskis>
> >> 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]
> >
> > 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
> > problem.
>
> 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?)
>
> > Instead of engineers making design and implementation decisions, managers
> > are by MISRA invited to make (or not make) them.
>
> 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*
> you??

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.

w..

D Yuniskis wrote:

> Hi Walter,
>
> On 5/15/2011 11:23 PM, Walter Banks wrote:
>
> >> It's the same sort of mentality that seeks to impose "style
> >> guidelines" on code in an attempt to make it more readable,
> >> maintainable, etc.  People end up working to appease the
> >> Standard's God instead of focusing on the product they are
> >> preparing.
> >
> > Coding standards misra and others do a lot to make big projects
> > much more reliable. They tend to force people to use clear
> > statements devoid of the kind of one of programming tricks
> > that create debugging and application nightmares.
>
> Coding *guidelines* can have the same effect -- without the
> "policeman".  If your staff aren't competent enough to
> understand the costs and benefits associated with different
> language features, then you have bigger problems than a
> "standard" can fix.
>
> > I have seen a lot of code written by many different people
> > the best fastest and most easy to maintain code is simple
> > and clear and let modern tools do there work.
> >
> > misra is a low cost standard well worth the cost.
>
> The "cost" of an e-file isn't the issue.  Rather, the cost
> of BLINDLY (i.e., following the "shalls" and "shoulds")
> adhering to it can be significant!
>
> Standards cost a lot more than the "paper" they're written
> on.  Someone has to codify an enforcement policy for your
> organization, put in place mechanisms to verify compliance,
> maintain any tools that are required for these activities,
> educate users as to why rules that obviously have significant
> coding consequences are BLINDLY enforced ("Yes, we value you
> as an employee... we just don't think you are smart enough
> to know when *to* use a goto/break/continue/etc. and when
> *not* to -- so we'll just make it illegal to use them!"),
> determine (in some empirical manner) if the costs are being
> justified by productivity increases, etc.
>
> Or, go the DoD route -- impose heavy-handed "requirements"
> on the code, the coding *process*, specification, testing,
> etc.  *That* sure seems to have worked out well for *them*,
> eh?  ;-)

Coding standards are a lot like author standards from a
publishing house. They are a way to create a consistent
implementation. BTW the DoD route does work. Some
of the best development groups that I know have serious
standards in place that they follow.

The 20% coding costs that you quoted elsewhere is
about double the cost of coding and debug of many
big projects that I know. Good software is engineered
and not a black art and good engineering standards
and practices produces products that are lower cost
and more reliable.

w..

Hi Walter,

On 5/16/2011 7:25 AM, Walter Banks wrote:
>> 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*
>> you??
>
> You have just made good arguments for design standards.

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
overhead).

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"
repeatedly.

> 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.

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.

>-----< Chris H >
> This is only a problem if the managers or programmers don't fully
> understand what they are doing.

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


> After 4 decades I have yet to be
> convinced that either group knows what it is doing any better than the
> other.

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 &Ouml;stman

D Yuniskis wrote:

> Hi Chris,
>
> On 5/16/2011 12:14 AM, Chris H wrote:
> > In message<iqp21t$pag$1@speranza.aioe.org>, D Yuniskis
> > <not.going.to.be@seen.com>  writes
> >>
> >> Or, hope for the benevolence of "key players" in those industries
> >> to underwrite all or part of their efforts.  Things like Standards
> >> are so tenuous that you have to be wary that The Industry might
> >> just pick up and head off in a different direction regardless of
> >> your concern/interests.
> >>
> >> The problem with "paid" organizations promoting/sponsoring things
> >> like this is they tend to be self-perpetuating.  They have a
> >> vested interest in "their" Standard.  So, the biological organisms
> >> involved in it have a *huge* stake -- their SALARIES!
> >
> > Then there are no standards you can rely on.
>
> What prevents me from relying on *any* standard (guideline) that
> I choose?  Why does it have to have an organization behind it?

One reason is an organization is likely to have a broader
base of experience than most individuals.

> MISRA isn't trying to define something akin to interoperability.
> I.e., defining a consistent API, etc. so code from vendor A
> works with vendor B.  So, there is nothing "shared".
>
> I can take MISRA (or any other "standard"), drag out a red pen
> and mark it up to my heart's content, laminate it between two
> sheets of clear plastic, write "Company Guidelines" across
> the top and now I have a "standard that I can rely on".

Do you have reasons why your red pen markings make the
resulting code written by your *standard* is likely more reliable
than code would otherwise be? If so you have a start.

> Does the fact that *this* company (and not *that* organization)
> has assumed ownership of it make it any less reliable?

Maybe. Automotive company development groups adopt
standards for their development. Their developers are amoung
the brightest around. Even small groups have serious coding
standards and their work is subject to peer review.

Before you point out the obvious failures in automotive code
divide the failures by lines of active code and compare to
your own work.


w..

Hi Walter,

On 5/16/2011 7:50 AM, Walter Banks wrote:

>>>> The problem with "paid" organizations promoting/sponsoring things
>>>> like this is they tend to be self-perpetuating.  They have a
>>>> vested interest in "their" Standard.  So, the biological organisms
>>>> involved in it have a *huge* stake -- their SALARIES!
>>>
>>> Then there are no standards you can rely on.
>>
>> What prevents me from relying on *any* standard (guideline) that
>> I choose?  Why does it have to have an organization behind it?
>
> One reason is an organization is likely to have a broader
> base of experience than most individuals.

Sure, but a firm isn't limited to the experiences of one or two
"individual employees"!

>> MISRA isn't trying to define something akin to interoperability.
>> I.e., defining a consistent API, etc. so code from vendor A
>> works with vendor B.  So, there is nothing "shared".
>>
>> I can take MISRA (or any other "standard"), drag out a red pen
>> and mark it up to my heart's content, laminate it between two
>> sheets of clear plastic, write "Company Guidelines" across
>> the top and now I have a "standard that I can rely on".
>
> Do you have reasons why your red pen markings make the
> resulting code written by your *standard* is likely more reliable
> than code would otherwise be? If so you have a start.

I have been (and continue to be) lucky in that I work with
competent individuals and organizations.  So, my experiences
are biased -- no "newbies" to drag down code quality "unattended".
I can't think of a *released* product I've been involved with that
ever needed a recall or field upgrade (other than to provide
optional or advanced functionality).  So, I guess the people
and processes that I have been involved with work "good enough"
(without selling $600 toilet seats  :> )

In almost every case, there was a "pride of ownership" involved
that kept folks on their toes.  *You* didn't want to be the reason
the product failed, etc.

With bigger firms, I found that people spent time finding a place
to "duck for cover" if things started getting sour.  Interestingly,
these same firms were the most likely to try to legislate the
development process.

>> Does the fact that *this* company (and not *that* organization)
>> has assumed ownership of it make it any less reliable?
>
> Maybe. Automotive company development groups adopt
> standards for their development. Their developers are amoung
> the brightest around. Even small groups have serious coding
> standards and their work is subject to peer review.

And are those RIGID STANDARDS or FLEXIBLE GUIDELINES??

When I sit in a code review, if I see a "goto", I don't
immediately think, "Ah, this guy is an idiot!  Doesn't
he know you shouldn't *use* goto's?"  Rather, I go looking
to see *why* he *chose* to use it -- KNOWING that it would
attract our attention.  (i.e., I assume he is competent)

We don't spend any time arguing about other ways that he
could (possibly) have eliminated that goto in favor of a more
structured flow.  Instead, we look at it as an example of
a situation that *we* may someday be faced with *or* an
indication of a serious flaw in the design specification
(which had been previously approved -- so what might *we*
have specified wrongly?)

In no case do we tell him "rewrite this to remove the goto".
(nor does The Boss have to sign a statement saying "goto's
are acceptable in this project")

> Before you point out the obvious failures in automotive code
> divide the failures by lines of active code and compare to
> your own work.

And multiply by dollars spent?

I've worked in automotive, medical, navigation, pharmaceutical,
process control and gambling & gaming industries.  All have
varying degrees of standards/requirements -- many of which are
*statutory* (by far, the most stringent are gambling).  I've
rarely seen "rigid standards" imposed on the code (though often
the *process* is heavily scripted) aside from DoD Ada (which,
you will note, the DoD has backed off of its initial goal of
having Ada used *exclusively* for their projects... I suspect
far more code is written in C, there, than Ada!)

By far, the best bang for the buck comes from specification and
testing -- not constraints on the code itself.