Bad Code Metric – Crap4J

A single number representing whether you’re six months worth of coding is actually not crap. Not code coverage, Checkstyle warnings or defects per thousand lines of code but a single score.

crap4j.png

Alberto Savio of Agitar Software presented on his new Crap4J tool at an Agile Open California session this week. Crap4J produces a single number defined by the following equation:

CRAP(m) = comp(m)^2 (1 - cov(m)/100)^3 + comp(m)
m = method comp(m) = Cyclometric complexity of method m. cov(m) = Test code coverage for method m.

In written terms:

Complexity bad. Tests good.

Right now there’s just an Eclipse plugin to try it out. Anything with a Crap number of 30 or above is a crappy method. And any project with more than 5% crappy methods is a crappy project. Alberto explained they wanted it to be an Agile metric so that it actually got used out there and part of that was keeping it simple. The other factor is it can easily be adjusted based on feedback and running it against many codebases.

What if you have a CRAP codebase? You can attempt to game the number to bring down the number of crappy methods. And how do you do that? You just write more tests against the high CRAP methods. And then it starts to occur to you that you could refactor as well. Gaming the system is writing tests plus refactoring. You can focus on a single number and encourage good behavior.