How Crappy Is Your Java Source Code?
December 7th, 2007 by Angsuman ChakrabortyHow 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, Enterprise Software, Headline News, How To, Humor, Java Software, Open Source Software, Programming | | RSS 2.0 | Trackback this Article | Email this Article
Add to Technorati Favorites
December 7th, 2007 at 9:19 pm
OHH NO, Another plugin
Don’t we already have plugins that do that ?
Also, It seem’s to check for two things only (complexity and coverage)
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 :
This inspection reports any instances of methods that have too high a cyclomatic complexity. Cyclomatic complexity is basically a measurement of the number of branching points in a method. Methods with too high a cyclomatic complexity may be confusing and difficult to test.
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
December 9th, 2007 at 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.
December 9th, 2007 at 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.
2) What’s out there in the market (both free and commercial) that does the same thing(or similar).
3) If there are any OSS products, why did they choose to create this one instead of contributing to the other.
3) Why is their product different.
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?