McCabe and others have created ways of using the complexity metrics to create more meaningful tests. For instance, see the paper "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric" (Thomas McCabe and Arthur Watson, NIST Special Publication 500-235, http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/title.htm).

Gotta start somewhere
Plenty of vendors sell tools to measure v(G). McCabe himself has highly regarded, although pricey, products. See www.mccabe.com. It's one of the few tools that will draw graphs of each function to clearly illustrate the possible paths.

There's a freebie Eclipse plug-in available from http://eclipse-metrics.source forge.net/ that looks interesting. Other open-source products are available on Chris Lott's site (http://www.chris-lott.org/resources/cmetrics/).

I used RSM from M Squared Technologies (www.msquaredtechnologies.com/index.htm) for gathering the numbers here. It's an inexpensive tool that acquires lots of useful metrics from source files. An evaluation version limited to 10 files is free. It's fast (except on insanely huge code basis like Linux) and easy to use with practically no learning curve. Highly recommended.

v(G) is not the only measure of complexity, and a lot of researchers prefer alternatives. But it's easy to interpret and plenty of tools exist. Like a lot of things, it's imperfect, but in life, just as in school, a 90% is often an A grade. It's a step in the right direction of being more quantitative about software engineering.

Finally, cyclomatic complexity says nothing about the "goodness" of the code. I ran this truly horrible program (www0.us.ioccc.org/2001/williams.c.), an entry from the International Obfuscated C Coding Contest, and found its average v(G) is about half of Grep's!

Jack Ganssle (jack@ganssle.com) is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack click here .