So how do typical packages stack up? Here are some results from my lab using the RSM tool (described later).

Apache 2.2.8, the open source web server, is composed of 5,752 functions with an average cyclomatic complexity of 6.04. Although 61 functions exceed 50, just under 5,000 are below 10. One scored a terrifying 725! That function--a single function, mind you--is 2,700 lines long with 145 cases and 353 if statements. If a v(G) of 100 indicates an untestable chunk of code, it's hard to imagine what 725 implies.

What about Linux? Kernel version 2.6.23 is composed of 161k functions. RSM, which was nearly instantaneous in most of the other experiments, needed 3 hours to digest the over 3 million lines of code. It generated a 200-MB HTML file that crashed Internet Explorer and Firefox, although trusty Ultraedit handled it, albeit slowly. Functions averaged a very respectable complexity of 4.94, with one peaking at 352. That 1,800-line function is practically devoid of comments and is unacceptable software.

Over 54,000 scored 1, suggesting that a third of all Linux functions are tremendously simple. 144k were under 10, but 764 are in the scary over-50 category, with 125 falling into the "untestable" over-100 bin.

Linux scored far better than the handful of GNU tools I checked. Grep, for instance, averages 13.52. The worst function's v(G) of 53 (in 128 lines of code) is lightly commented and almost exuberantly sprinkled with gotos, continues, and breaks.

On the embedded front, the open source RTOS eCos's 175 functions averages a remarkably low 2.54 with only six over 10.

With only 2,495 lines of code and 75 functions, FreeRTOS, another open source RTOS, is much smaller than Linux. It's average v(G) is just 3.44. One function scored 11; all the rest are under 10.

µC/OS-II averaged a very respectable 5.85 for its 118 functions, with one outlier at 25. That outlying function was composed of the switch structure McCabe says shouldn't be counted when running these metrics.

Testing
A lot of people ask me "how much testing is enough?" That's a tough question, but, since v(G) is exactly the number of paths through the function, it's clear that the metric is also exactly the minimum number of tests needed to completely exercise the routine. If your regimen has less then v(G) tests, the code is not completely tested.

Cyclomatic complexity doesn't tell us how many tests are required; the number could be much higher than v(G). And the number by itself tells us nothing about whether the correct tests have been run. But it's a quick sanity check that lets us know if we have conducted the necessary minimum number of tests.

So that 2,700-line Apache function needs--for one function--at least 725 tests. Ouch!

Of the three RTOSes I looked at (µC/OS-II, eCos, and FreeRTOS), total cyclomatic complexity (the sum of all of the individual v(G)s) is 690, 445, and 258 respectively. Note that these numbers say nothing about the comparative quality of the code as those that offer more functionality will have more functions and higher total complexity. But to those of you who think you can write an operating system in a weekend, well, it's clear that just writing the tests will consume far more time than that.

Apache's total complexity is 34,764; Linux sums to a whopping 798.092. If each test requires merely four lines of code, the test suite will equal the size of Linux itself.

And that says something about the difficulty and expense of creating comprehensive tests.