CRAP or CRAPpier?
If you've been following the testingReflections feed then you would have noticed announcements about CRAP4J.
CRAP is a metric recently devised to help developers avoid obtain feedback about certain elements of code quality.
CRAP = "Change Risk Analysis and Predictions"
CRAP4J is the java implementation of a tool that calculates and presents the metric.
There are only two dimensions (currently) - cyclomatic complexity and code coverage... CRAP is a function of the two.
This is great and I encourage it... but are these the only two facets of code that we need to measure to evaluate quality in terms of risk of change?
I doubt it.
I don't discourage people from using CRAP4J, however I do suggest that people understand the limitations of the metric... there's a whiff of leaky abstractions here that it would be all too easy for people to read too much into the metric if they don't understand the value add of the metrics that it is based upon. Worse still, placing too much faith in the metric without understanding it may lead to fixing one problem and introducing a new, worse "risk of change" issue that CRAP isn't measuring (yet).
One thing in particular bothers me ever so slightly...
Some very smart people we talked with believe that if you have 100% test coverage, your risk of change should be 0. Bob and I, however, believe that more complex code, even if it’s fully protected by tests, is usually riskier to change than less complex code.
Although this may be a belief - a hypothesis - is it proven?
Jason Gorman has been asking these sorts of questions about 'Code Quality Metrics' and the 'change risk' for a while now. He's been challenging the assumptions behind several of code-quality metrics. It turns out that many 'code quality' metrics are based more on belief than actual scientific proof. Jason is challenging these beliefs, scientifically, and I recommend following Jason's blog to keep up to date on where he is with his efforts.
Perhaps some of his research will influence how CRAP, as a metric, evolves.
So, do draw upon tools like CRAP4J but be wary of its basis and understand the metric... supplement it with other metrics... scientifically prove that it is reducing 'risk of change' when you have less CRAPpy code and be wary of the metrics equivalent of leaky abstractions.
