How Crappy Is Your Java Source Code?
By Angsuman Chakraborty, Gaea News NetworkFriday, December 7, 2007
How crappy is your Java code? Often we find others code crappier than ours, especially if we are given to maintain their code. Crappy code authors are almost always happy with their code quality. Can we quantify crappiness?
Crap4J claims to be able to quantify crappiness in Java code with a simple formula (applicable to a method):
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.
Now you can go to your boss and quantitatively show him that your code is less crappier than your colleague*. After all managers like numbers, even if they have crappy & dubious validity.
*Remember to forget that Crap4J even exists, or discount it heavily at any mention, if your code turns out to be crappier than your competitor.
Note: CRAP stands for Change Risk Anti-Patterns according to their definition.
Crap4J comes as an Eclipse plugin and can also be integrated with Ant. Check the video for a nice demonstration. The authors decided to use 30 as a threshold for crappiness.
I partially agree with the idea but I am not comfortable with the formula. Also it ignores cross-method complexity introduced and complexity of a class as a whole which may not always be the sum of the complexity of the methods.
Tags: Ant, eclipse
|
December 9, 2007: 11:48 am
In my first comment I said ‘Not another plugin’. I did that because often times I question the motives behind what some of the OSS guys are upto. My suggestion for anyone coming up with an open source product is to provide justification for it by 1) Telling what they are doing. I think, lot of people , who wasted countless hours evaluating these products can relate to what Iam saying. Another metric I apply to OS products is this: If it costed x dollars would I buy it? |
|
December 9, 2007: 9:42 am
> Anyway,I don’t know anybody who wants their code to be called crap. I have seen code worse than crap. However as you said nobody would like to call their own code crap. > My experience tells me that spending a little time in the beginning to think through the problem will go a long way in writing quality code and you don’t need as my test cases(especially trivial ones). While it may be true for the experienced programmers, even they can benefit from good unit testing. As for the rest unit tests go a long way in creating reusable quality code. I have sent you an email wrt. your problem with our comment protection. |
 krishna |
December 7, 2007: 9:19 pm
OHH NO, Another plugin Anyway,I don’t know anybody who wants their code to be called crap. But it’s a nice way to get our attention for their plugin. I use IntelliJ IDE and most of what I do is web developement (JSP,javascript and form handlers). My experience tells me that spending a little time in the beginning to think through the problem will go a long way in writing quality code and you don’t need as my test cases(especially trivial ones). Coming back to IntelliJ , the IDE has many inspections by default that it can run on your code and I went back to check for this and found it. The inspection say’s this : Another reason for me to love it BTW, your spam guard kicked me out twice when using Opera. Iam trying this with FF.Let’s see |
krishna