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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reason behind MISRA rule 111
Started by ●May 12, 2011
Reply by ●May 16, 20112011-05-16
Reply by ●May 16, 20112011-05-16
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?)
Reply by ●May 16, 20112011-05-16
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?]
Reply by ●May 16, 20112011-05-16
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..
Reply by ●May 16, 20112011-05-16
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..
Reply by ●May 16, 20112011-05-16
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..
Reply by ●May 16, 20112011-05-16
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.
Reply by ●May 16, 20112011-05-16
>-----< 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 Östman
Reply by ●May 16, 20112011-05-16
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..
Reply by ●May 16, 20112011-05-16
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.