Posted by Thomas M. Tuerke on August 1, 2017
“Let’s make the incision … There we go … Spreader.”
“Good. A little wider. Like that. Metzenbaum.”
“There we are. We’re at the DIVIDE_BY_ZERO site. As you can see, it starts here, and follows this path here. We’ll remove it … gently … nice, a clean extraction. Now, let’s graft in a check here … and done … hmmm … see that? I think we have some DEADCODE here, too. Please put up the results of the latest scan.”
“Here you go.”
“Just as I thought. We’ll have to extract that as well. Monopolar.”
“Good, it’s coming out nicely, too. Wait. Mosquito.”
“No, a real mosquito just flew in. Will somebody please close that screen door?”
Okay, so fixing bugs is nowhere as dramatic as a medical thriller, but the point here is that it is ludicrous to perform a surgical procedure in a place where bugs of every stripe and variety can get in faster than you can remove them.
The very same holds true for software development.
Synopsys Static Analysis’ world-class portfolio of checkers is like a well-stocked operating room (OR), ready to detect and guide you in removing countless crippling defects from your project’s source code.
But, unless your development is happening in a “hygienic” environment, you might as well be performing open-heart surgery in a straw hut along the Amazon River.
So, what does “hygienic” mean in a code development context? Keeping sick developers at home until they’re better? Handing out bottles of hand sanitizer? Routinely cleaning that crud off the keyboard that invariably builds up? (Yeah, ewwww!)
As helpful as those ideas might be, we’re not talking about biological infestations, but rather the digital ones: logic bugs that make our code do something other than we intended… especially those with disastrous consequences.
In the medical world, hygiene is not a product, but a process: tools you use and procedures you follow to prevent infection. Sure, doctors may have an autoclave to sterilize tools, but it’s no good if they then touch those tools with dirty fingers. Yup, doctors scrub up, wear gloves, and observe many other protocols that significantly reduce the life expectancy of nasty bugs in their domain.
Similarly, you may have a static analysis tool to find logic bugs in your code, but you’re fighting an uphill battle if the “fix” just allows another bug in. Yes, the next analysis run may catch it, but doesn’t that smack of “never time to do it right, but always time to do it over?” That’s not really an efficient use of developers’ time.
Okay, so I’m holding up the medical profession as an example, and for good reason. Despite there having been medical professionals around for millennia, it wasn’t until about a century ago that the profession embraced the notion of germs being “a thing”… and that certain procedures, like washing hands and sterilizing tools, could radically improve the outcomes of their efforts. Many physicians had to be dragged – kicking and scratching – into the new age of medicine.
And so it is today with software. Many of us developers still maintain a cavalier attitude about the code we write. “Oh, it’s fine. Sure, the C standard says bit-shifting by a negative value is ‘undefined,’ but the compiler gets it right.”
“I don’t need to test the return value of that function call… sure, it could fail, but not the way I’m using it.”
“const-schmonst. I know not to ever change that pointer, so making it const is a silly waste of time.”
“Using a double as this for loop’s variable has worked just fine for years!”
“This library’s allocation code doesn’t do anything with the deallocated memory, so this assignment after a free is harmless.”
While there may be inklings of truth to each of these positions, in the bigger context, they result in more frail code. Each of these positions should seem as ludicrous to a good software developer as the protestations of a reluctant doctor exclaiming “Wash my hands? My hands are clean. Why, I even had them manicured last week!” (Bonus points to the reader who correctly cites what movie that came from.)
Not a tool like a scalpel to find and remove bugs, MISRA instead offers hygienic practices to follow for not writing frail code. By avoiding the less reliable aspects of C and C++, your developmental outcomes – just like surgery in a clean OR – have a better chance of success. In software terms, project survival by delivering more reliable code on time.
As we’ve previously said, some of these rules seem fussy to some, just like wearing those paper frocks and caps in the OR might have seemed at first. But history will show they make sense.
Good sense, because good developers recognize that compilers and libraries change: that “well-behaved” but nonetheless undefined behavior you were counting on from Compiler X may not carry through to Compiler X+1, or Compiler Y, or even Compiler X with different options. And developers change, too, so “I know X…” won’t hold true when that happens.
MISRA isn’t free, though. I’m not talking about the negligible cost of purchasing the standards documents. Rather, if your coding environment hasn’t been too sanitary, you’re likely to face a steep ramp-up cliff. Like scrubbing down a heretofore-unsterilized OR then teaching the staff how to not re-contaminate the place, you may take a hit if you want to bring MISRA into a development environment that’s not used it before. It’s not just coding rules, but organizational practices as well, that need to be put in place. That’s one of the reasons why MISRA recommends you adopt it at project inception, not later. Retrofitting hygiene is rather disruptive.
But just like doctors wouldn’t dream of entering an OR without being scrubbed and suited up, MISRA soon becomes second nature to a development shop, where developers – habituated to the procedures – churn out code just as they did before. Only, it’s more reliable. They will be spending less time fixing bugs, because they will have prevented many of them from getting into the project in the first place.
More and more, down-stream consumers of software – keen to themselves provide reliable software – are insisting on up-stream component vendors producing code in a properly hygienic environment. Namely, developed in a MISRA-compliant way.
In fact, it may be stipulated by contract. Part of the MISRA process involves an audit trail so you can prove that you’re compliant. So, a project being MISRA-compliant improves your competitive position in winning such contracts.
The medical profession has pretty much gotten rid of “quack” doctors – those who didn’t take hygienic practices seriously – and the world has been made better for it. As reliability becomes more and more crucial to modern software, we can see the same sort of shake-out happening in our industry. No doubt there will be intransigents that will steadfastly refuse to step into the new era of software development, but competitive forces will relegate them to the sidelines while those who have cleaned up their act take more and more of the market “pie.”
The choice is up to you. Because reliability matters.