CRAP

I’ve written about Crap before. It’s a very clever metric that combines test coverage and cyclomatic complexity. You want to keep this metric low. (FitNesse is currently at 0.07). Crap will skyrocket if you have a method with high CC and no coverage. You can bring it down if you 1) split the method up into a group of low CC methods or 2) cover the method with tests or 3) both.

One of the more useful elements of CRAP is that it measures the “crappiness” of individual methods, and provides you with a list of the worst. (Fitnesse has very few crappy methods at the moment.) This list of crappy methods gives you targets to attack. You see a method whose CRAP metric is 30, or 50, you target it for decomposition and coverage. In this way you can engage in a program to bring the “Crappyness Trend” (i.e. the ratio of crappy methods to total methods.) down.

What is the benefit of brining crappiness down? Apparently there is a strong correlation between CC and defects. So an effort to either reduce CC or increase coverage in high CC modules seems an appropriate way of reducing defects. Of course the real reason to target crappy modules is that CRAP is a measure of care—or rather it’s lack.

If you have high CRAP numbers it simply means that you have been careless with your code. Big CRAP means that your methods are long, complicated, and untested. And that’s just slovenly behavior. Sorry, that’s just the way it is.

The Braithwaite Correlation

Despite the fact that this metric sounds like a movie title, this metric excites me. The creator, Keith Braithwaite is duly humble about it; but I think it’s a significant discovery. The math behind the metric may be a bit hi-falutin for some folks, but the logic is very compelling. If you don’t know what the terms “scale-free”, “power-law”, and/or “log-log” mean, don’t worry. It wouldn’t hurt you to learn these concepts, but the bottom line is very simple.

The Braithwaite Correlation is simply a measure of how many methods have high Cyclomatic-complexity. Well, OK, that’s not precisely true. It’s actually a measure of how CC is distributed amongst all the methods. Suffice it to say that if this number is small, then many methods have a high CC. (notice the inversion.)

Now here’s the interesting bit. BC is not dependent upon the size of the program being measured. Two different programs that have the same BC, have the same distribution of CC amongst their methods. One program may have a thousand methods, and the other may have only 20, but the distribution is the same. Therefore BC can be viewed in an absolute sense. For example, we can say that we want our programs to have a BC > 2.

Actually the number 2 seems to have a special significance. Keith’s research so far shows that programs developed with TDD almost always have a BC greater than 2. Whereas programs developed without TDD almost always have a BC less than 2. (FitNesse currently has a BC ~= 2.88)

What is the value of measuring BC in your code? If BC is high it means that your methods are generally small and simple, and that very few are large and complex. If BC is low, it means that more of your methods are larger and more complicated. And since we know that CC is strongly correlated with defects, we can surmise that high BC correlates with low defects.

But again, the real reason to keep BC high is that it simply reflects a greater amount of care.

Conclusion

The conclusion is simple. These metrics are easy to measure¹ and so you should be measuring them now. What’s more, these metrics (especially CRAP) tell you where to focus your energies. You can take action that will have an immediate and direct effect on the quality of your code that correlates to defect rate.

So what are you waiting for?

¹ For java programmers the tools already exist to measure these metrics, and they are very simple to use. For everyone else, the tools that calculate CC and coverage are readily available. Combining them to calculate these two metrics just isn’t that hard.