In “Assertingfailure ,” Jack Ganssle’s most recent blog on Embedded.com, he presentsa strong case – again – for the use of the assert( ) macro as a way for developersto use the C language to debug itself.
His column and a number of other contributionsby a variety of authors are included in this week’s Tech Focus on “Gettingassertive about code quality.” In addition, it also includes a numberof articles and columns on other mechanisms, such as the X-macro and the offset()macro, to achieve the same goals.
After researching the topic for this week’s Tech Focus newsletter, I went through the books on C programming and debuggingI’ve read over the past decade or so and double checked how extensive thecoverage of assert () and other useful C macros has been.
I was surprisedat how little space was devoted to their use, given how extensively theyare employed – and debated – within the programming community. Of the 18C programming books I found in my library, only five or six discuss assert()or any of the other useful C macros, and half of those devote at most no more than oneor two pages to the topics.
Only a few go into any useful detail. One is “WritingSolid Code,” by Steve Maguire, a supporter of its use. He devotesan entire chapter to how to deploy it effectively without any of the gotchas.The other, “Scienceof debugging” by Matt Telles and Yuan Hsieh, also covers its use in achapter on Predebugging. More accurately, they expend much effort in detailingwhy its use is to be avoided.
”Frankly, we do not see the value of asserts in producing qualitysoftware, ” they write. “In fact, we believe that the usage of assertsis the mark of a lazy programmer. We believe that asserts can increase theodds of bug formation and introduction, and that usage of asserts shouldbe avoided. ”
In addition to Maguire, coming to the defense of assertions areBrian Kerrighan and Rob Pike (ThePractice of Programming), and Steve McConnell (CodeComplete). This dichotomy about their use is reflected in a numberof technical conference and journal papers I have found on the web surveyingthe opinions of software developers, including:
But in “Assessingthe Relationship between Software Assertions and Code Quality,” the authorsdid more than survey the opinions of software developers. They did theirbest to pin them down to actual results. Then, using a variety of rock-solidstatistical methodologies they have come up with an impressive positive correlationbetween assertion density and code quality: the more assertions, the betterthe quality of the code.
In the embedded environment, as Jack points out in several other blogssuch as “Adifferent take on asserts,” and “Theuse of assertions,” the doubts about it's use have included: 1) inmany space and performance constrained 8 and 16 bit MCU designs, it takesup valuable memory space and 2) it imposes additional performance overheadon the MCU. But as he points out in his mostrecent blog, “with the proliferation of 32 bit MCUs most of theseconcerns go away. ”
If this shift is coming, it may mean serious consideration will be givenin embedded designs to another related technique that Jack strongly supports:design by contract(DBC). Several especially useful blogs by Jack on the topic are:
“DBC is like assertions on steroids ,” Jack writes.”With DBCone defines contracts, which are assertion-like statements about functions'input and output parameters (pre- and postconditions), as well as thingsthat never change throughout the execution of the function (invariants).On their wedding day, the betrothed say ‘I do;’ they enter into a contractualarrangement that is an invariant underlying all of their future relationships . ”
I doubt the debate about the use of assertions (and other C macros) willgo away any time soon. But I finally have come to see the benefits of their use whenI read a comment made by Alan Turing in 1949 aboutthe assertionalmethod for proving correctness of programs.
“How can one check a large routine in the sense of making sure thatit's right? ” Turing asked rhetorically. “In order that the man whochecks may not have too difficult a task, the programmer should make a numberof definite assertions which can be checked individually, and from whichthe correctness of the whole program easily follows. ”
Interestingly, his comments were made at just about the time JohnVon Neumann and a team of scientists and engineers at the Instituteof Advanced Studies were starting their work on the first computerbased on Turing's concepts – and writing programs to run on it, without theaid of any of today’s modern debugging and static analysis tools.
Embedded.com Site Editor Bernard Cole is also editor of thetwice-a-week Embedded.comnewsletters as well as a partner in the TechRite Associates editorialservices consultancy. He welcomes your feedback. Send an email to , or call928-525-9087.