Embedded Systems Design - March 2008 - (Page 49)

0308esd.p49to52 2/13/08 8:11 PM Page 49 Name Ganssle BY Jack G.Here break points Taming software complexity “D ebugging is twice as hard as writing the code in the ﬁrst place. Therefore, if you write the code as cleverly as possible, you are, by deﬁnition, not smart enough to debug it.” Folk wisdom, as reflected in Brian Kernighan’s clever riff on clever code, is that insight we all know but generally ignore. But how can we measure “cleverness?” Supreme Court Justice Potter Stewart, trying to characterize pornography, memorably lamented that it somewhat defies definition, but “I know it when I see it.” Likewise, most of us can sense excessively clever code but may disagree when examining specific code chunks. We do know complicated functions are tough to understand, an agony to debug, and usually require excessive amounts of maintenance. One of the tragedies of software engineering is that, in industry at least, we’ve successfully avoided the metrics-based quality revolution that transformed manufacturing. Few companies know their pretest bug rates in, say, defects per line of code. Or productivity in lines of code per hour. Or which are the worst functions in a project. In an experiment I conducted surreptitiously last year, only a third of correspondents could answer the seemingly simple question “how big is your code” in any metric they wanted to use (MB, lines of code, lines they developed, value in dollars, or, A simple equation can help you measure the complexity of your code. heck, the weight of the listings). A management mantra states “if you can’t measure it, you can’t manage it.” Though surely true for building widgets, it’s a lot harder to apply to engineering. But some objective measures provide valuable insight into the art of developing firmware. Since we know complex functions are problematic, it seems logical that we measure and control complexity in functions. And it turns out that’s pretty easy to do. But first, there are two kinds of complexity: essential, which is a quality about the problem being solved, and incidental, which is the complexity introduced by our engi- neering approaches. Here we’re talking about incidental complexity, as that’s the only kind we as developers can manage. Thirty-one years ago, Thomas McCabe proposed a metric called “cyclomatic complexity” to attach a quantitative measure to a function’s complexity. It’s one of many such measures but is by far the one most used. It measures the number of “edges” and “nodes” in a function, where a node is a computational statement and an edge represents the transfer of control between nodes. Cyclomatic complexity is then: v(G)=edges–nodes+2 Note that many different formulations of this equation are in the literature; this one is the simpliﬁed calculation that’s usually used and was given in McCabe’s original paper (“A Complexity Measure,” Thomas J. McCabe, IEEE Transactions on Software Engineering, Volume SE-2, No. 4, December 1976, p 308-320). Also note that “edges” include the flow between two sequential statements. Thus adding nonbranching/non-looping statements doesn’t change v(G), which is essentially the number of paths through a program. Hopefully that last statement illuminated a light bulb in your head with regards to testing. More on this later. LIMITS It’s reasonable to assume (and experience proves) that functions with high cyclomatic complexities will be buggier than simpler functions. In fact, HP found a correlation coefﬁcient of 0.8 between v(G) and defect density 49 Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. www.embedded.com | embedded systems design | MARCH 2008 http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - March 2008

Embedded Systems Design - March 2008 Contents #Include Programming Pointers Designing DSP-based Motor Control Using Fuzzy Logic Hardware/Software Verification Enters the Atomic Age Efficient CRC Calculation with Minimal Memory Footprint Programming Your Own Microcontroller Advertising Index Break Points Marketplace

Embedded Systems Design - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.