The director of software development comes into your office in a panic. “We’ve got to do MISRA… stat! Legal insists on it; our customers are demanding it.”
Your heart sinks.
If you’ve ever been to Yosemite, you’ll know there are two ways to the summit of Half Dome: one way has fairly gradual—or at least manageable—slopes, and a lot of support.
The other is straight up the cliff.
In the blink of an eye, you now find yourself in something like the latter situation, craning your neck as you contemplate an assault on the sheer face of Mt. MISRA.
You have your work cut out for you. Had you known at project inception, you could have planned to take the gentle path up, but that’s not an option anymore.
Okay, first, sit down and breathe. Vertigo is no good, neither to a climber, nor to somebody who has had this sudden course change thrown their way. You need perspective.
Start by coming up to speed on a few things. Sure, MISRA: but which flavor? If it’s stipulated by contract, your choice may be set. MISRA addresses both C and C++. Your codebase will naturally dictate which—or if both—will be necessary. But right now, the C version has a more recent 2012 release and an older 2004 release. Unless a contract stipulates otherwise, you’re generally better off going with 2012. For C++, there is only the 2008 document. Note that the two language standards are similar, but not quite the same. (No, you do not need to apply MISRA C to your C++ codebase, or vice versa. But, if you have a hybrid codebase, you may need both.)
If you don’t have a copy yet, buy the appropriate standard. While you can get a dead-tree edition, ordering the PDF is both cheaper and quicker into your hands.
Then read it. Not just the rules, mind you; the material before the rules needs a good going over too. Take the supplemental “MISRA Compliance: 2016” document to heart as well. Remember, successfully climbing Mt. MISRA is mostly about technique. You’re going to have to establish how to implement those techniques in your particular circumstances. You, and your management team. Remind them that they will be active participants in this.
Subsequently called a “guideline enforcement plan.” Basically, that’s a table of the rules in the standard, and how you’re going to enforce them. Some of MISRA can’t be verified using static analysis, and thus requires manual processes. Things like code reviews or documentation. Fortunately, this is only a very small subset of the rules. Synopsys’s static application security testing (SAST) solution can help you with the rest that analysis can find.
As I’ve previously said, MISRA can be fussy. If you’ve got a sizable codebase—and haven’t been particularly “hygienic” about certain coding practices—that’s a lot of opportunity for MISRA to be fussy.
It is quite possible for your first MISRA run to cause a defect avalanche, possibly generating an order of magnitude more defects than your previous analysis runs.
Of course, avalanches don’t go over well in any climbing expedition, so how can you avoid management sending out the search parties looking for survivors, cancelling the project in the meantime?
Any good rock climber will tell you, take one rock face at a time. In climbing Mt. MISRA, that advice holds true also.
There are many ways to attack it, but one is clearly better than the rest: divide your codebase into logical components—with as fine granularity as possible—and apply MISRA analysis only to one specific component at a time. Do so with scorch-the-earth rigor. Go through each file one at a time and address what the analysis finds. Naturally, this assumes that, as responsible developers, you have a well-honed test suite to ensure that your changes are innocuous. (If not, maybe you need to go back to base camp before going further. Otherwise, how would you know if your changes—any changes, not just involving MISRA—are in keeping with your expectations of what the software should do?)
The idea with this depth-first approach is that in short order you will have one component—ostensibly your most valuable one—completely MISRA compliant, and can then turn your attention to the next most important one. Remember, you get zero credit for partial ascents. There is no such thing as “mostly MISRA compliant.” Modulo contractual stipulations, it’s an all-or-nothing deal.
Slicing the other way—picking which rules you fix first throughout the entire codebase—is sub-optimal. Your project’s MISRA progress remains half-baked, and compliance is pegged at zero percent, until the last defect is fixed, when you suddenly are at 100 percent. Going component-by-component, you have measurable (as in deliverable) progress, with more and better options on how to proceed if you suddenly find yourself between a rock and a hard place.
Once a component is compliant, you subject it to ongoing MISRA analysis (in the broader compliance matrix sense) in order to keep the compliance intact…and immediately address any defects uncovered.
No discussion of MISRA—or any compliance regimen—would be complete without the mention of deviations.
That’s right. The rules are fussy, and the standard admits it. It’s not a one-size-fits-all standard. Sometimes you can avoid “fixing” the defect, “addressing” it by a deviation.
This is not a ‘get out of jail free’ card. Or, a quick back route to the summit. Generally, a deviation is both technical and managerial acknowledgement that the MISRA finding is legitimate, but that—in both the tech team’s and management’s view—the risk represented is acceptable because it has been mitigated by some means. Remember that the end result is reliability, so a deviation should not undermine that result.
It might be that, for example, a particular MISRA rule says such-and-such is a risky practice, but the technical team has determined that—for the compiler being used—the code generated is correct, that safeguards have been put in place to detect if the code generated ever changes, and that this suite of defects will be revisited if any of the above changes.
And then every instance of violation you want to claim a deviation on needs to cite that.
Yes. Paperwork. Accountability.
Frequently, it’s just easier to “fix” the code, but sometimes the only option you have is to deviate.
Also, the number and nature of deviations may also be stipulated by contract. Acceptable risk for you may not be acceptable for your customers.
In today’s development environment, not all code going into your project is necessarily “yours.” That is to say, you may use open source or other third-party code. Or you may be relying on code from other parts of your organization. Or, it may be generated by a tool not directly under your control.
The common take-away here: you may not have direct influence over that code’s state.
MISRA refers to this as “adopted” code. And while you’re still responsible for ensuring its reliability, you have certain latitude in the measures you take to do so. One option may be obliging that party to MISRA compliance as well, for example. But there are others, and which you select is dependent largely on your particular circumstances.
The successful climb requires a competent team, both technical and managerial.
Most importantly, management needs to be aware of the role they play, and be supportive of the MISRA effort. While seeking MISRA compliance may seem like a hindrance and a lot of overhead, it should be seen as an amortization of risk mitigation efforts that will pay dividends in more reliable code getting delivered sooner. Bypassing MISRA processes should be seen like asking someone to skip strapping on a harness and life line. Sure, the climb may be successful, but you’re taking risk by doing so. (Do this only if failure is an option.)
By the same token, the team needs to buy into the MISRA process, too. They’ll need to know what to do, both in terms of the policies such as how enforcement is done, and—more importantly—how to code so they don’t add to the MISRA defect count. This latter element in particular is important. They’ll just become better coders in the end. Sure, there will be the maverick types that bristle and resist, and there are strategies for dealing with them, not the least of which is not letting them move on to new fun tasks until they’ve finished the old. Odds are, they’ll be mired in bugs more so than their colleagues, anyway.
Knowing that MISRA is a reality, you’ll do yourself a favor by being prepared for it next time. Start each new project off with MISRA compliance already built into the development process. Just like a successful development team has processes for when and how bugs are filed, who works on what project, and what the deliverables are, so too having processes for how to analyze the code for MISRA violations and what the process is to address violations will stand the team in good stead. It will undoubtedly also help influence certain decisions like what third party components you select, heading off a compliance landslide before it comes tumbling down around you later.
Honestly, it will be a far smoother journey than a mid-project assault on Mt. MISRA again. And the techniques you develop now will make the gentle path far better.
More importantly, the results are not some intangible “compliance” attribution. The resulting code will be materially more reliable because fragile coding practices have been avoided, and the risk of subtle and possibly catastrophic bugs have been minimized.
Because reliability matters.
Note that this is deliberately not a detailed “how-to,” but rather a crude sketch, with many details glossed over, since individual development environments, project deliverables, and general circumstances are remarkably diverse. Thus, no advice given here could hope to cover even a small percentage of them in an article this size. Your particular route up the face of Mt. MISRA will necessarily involve your own assessment of alternatives, based on your own needs. You can reach out to the Synopsys team to begin exploring your circumstances, though, to plan your own path to the summit of Mt. MISRA.