What prevents me from relying on *any* standard (guideline) that I choose? Why does it have to have an organization behind it?
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".
Does the fact that *this* company (and not *that* organization) has assumed ownership of it make it any less reliable? The people who will be held accountable to it will have had a
*real* say in its creation. They will have *control* over its evolution. Your claim is that some third-party needs to be involved in order to make it *credible*/reliable??
(if my quality/performance is higher than yours, why do you care what my "standard" is?)
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.
[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 resentment!]
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" arbitrarily.
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 content...
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)
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*!)
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!)
If it works with any compliant pdf reader, then I'm happy. I've just seen too many pay-for "pdf" files that are /not/ pdf format (i.e., the don't follow the pdf standards, and only work with Adobe Acrobat).
These reasons are not doubt obvious to you, but they are not obvious to me. I understand that it costs a fair amount of money to run a group like Misra, and you need to get that income somehow. But as I've said elsewhere, I don't think charging for the document is the best way to get that money. Obviously, of course, you know far more about this than I do - I can only comment from the outside.
It's not that £10 is expensive - it's peanuts to a professional, and even the most hard-up amateur could find the money. But when it is paid-for and single-user, a company has to figure out and track who has the documents, how many they need, what are the rules for when the developer gets a new computer, etc., etc. If it's free, you download a copy and pass it around as needed.
Having a price - any price - makes it an exclusive club. If it is free, the knowledge can be spread around so much more easily - you'd find more information on the web, and more in discussions. The OP in this thread could have quoted rule 111 for everyone's benefit. Some things are worth more when they are free.
I had a little look at the forums, and they seem very useful - I definitely like the way they are organised by rule.
I am not proposing that outsiders be able to modify the documents themselves - that would be useless. But if you looked at the postgresql link I posted, you can see that it is user annotations at the end of the pages - not modifications to the pages themselves. Imagine that the MISRA standards were available in html format, with one rule per page, and at the bottom of each page was a link to the matching subforum and perhaps a copy of the most popular relevant forum posts.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
If you are unable to work to customer specifications and guidelines you seem unemployable.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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?)
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?)
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?]
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.
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.
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.
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.
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.
MISRA sort of claims to be able to mitigate that state of things.
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.
One reason is an organization is likely to have a broader base of experience than most individuals.
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.
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.
Sure, but a firm isn't limited to the experiences of one or two "individual employees"!
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.
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")
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.
That's *my* cost. How many projects outside of big shops do you know that can meet that goal? How many of these have you seen specifications, test suites, etc.?
Big projects, big shops impose lots of overhead. They justify it because of the size of the project, the fact that they need a large team, that there will be *big* variations in the skillsets of team members, that some significant portion of those team members may "move on" before the project is completed, etc.
Exactly. -------------------------^^^^^^^^^^^^
And your contention is that GUIDELINES are NOT EFFECTIVE? That you can't *trust* your staff to "do the right thing" without *enforcement*?
I try to design things (hardware, software, systems) so that it is easiest for those who follow me to "do the right thing". But, I don't *prevent* them from doing something *else* -- as I am not prescient. I trust them to know when to go in a different direction.
Substitute "guidelines" for "standards" and I heartily agree with your last statement!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.