[Change request] Support for the CRAP metric

[ueman]

DCM version

unrelated to the version

What problem do you want to solve?

I would like to see support for the CRAP metric. The metric basically assigns a method a numeric value for risk for bugs. It combines the cyclomatic complexity and code coverage in order to be able to.

It's described in http://www.crap4j.org/faq.html

Q: How is CRAP calculated?

A: The current version of CRAP combines the two change risk anti-patterns we just discussed: excessive method complexity and lack of automated tests for those methods.

Given a Java method m, CRAP for m is calculated as follows:

CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)

Where comp(m) is the cyclomatic complexity of method m, and cov(m) is the test code coverage provided by automated tests (e.g. JUnit tests, not manual QA). Cyclomatic complexity is a well-known and widely used metric and it’s calculated as one plus the number of unique decisions in the method. For code coverage we use basis path coverage. Low CRAP numbers indicate code with relatively low change and maintenance risk – because it’s not too complex and/or it’s well-protected by automated and repeatable tests. High CRAP numbers indicate code that’s risky to change because of a hazardous combination of high complexity and low, or no, automated test coverage.

Generally speaking, you can lower your CRAP score either by adding automated tests or by refactoring to reduce complexity. Preferably both; and it’s a good idea to write the tests firsts so you can refactor more safely.

Some more resources:

• https://testing.googleblog.com/2011/02/this-code-is-crap.html
• https://blog.ndepend.com/crap-metric-thing-tells-risk-code/

What do you think is the correct solution?

Implement the CRAP metric

Participation

• [ ] I am willing to submit a pull request for this change.

Additional comments

No response

[incendial]

A metric with the automated tests involved, interesting. Thanks!