I have to admit, when I first heard about the open source project Crap4j, I thought it was a joke. It sounded like a sarcastic, tongue-in-check spoof on the masses of brittle legacy Java code accumulating daily in software development shops around the world.
It isn’t a joke.
The Crap4j Web site describes the Change Risk Analysis and Predictions software metric as “a mildly offensive metric name to help protect you from truly offensive code.” Well said. The levity of the name belies the seriousness of the problem. Java is no longer a new language. Greenfield development has made way for maintenance and incremental upgrades to massive legacy code bases for which the original development team is long gone.
We all know legacy Java code is often poorly documented, but dig a little deeper and you’ll discover something even worse: it’s poorly tested! Now, consider that legions of developers have added little tweaks and bug fixes along the way without giving consideration to meaningful refactoring. What else can you do but throw up your hands (or your lunch) and declare “This code is crap!”
“Hell is other people’s code”
I don’t know the origin of that quote, but I first saw it here – and ain’t it the truth? But, I think one sign of my maturity as a developer was when I stopped holding former developers completely responsible for lousy, poorly written code. I look back over my career and realize I’ve written a bunch of crappy code myself.
How does it happen? We’re busy and forgetful. We hack out a few classes to prototype something with the best of intentions to go back and refactor it. But, who has time to rewrite working code when we’ve got deadlines to meet? We soon forget how much wreckage we’ve left behind. We never seem to get around to fixing that 500 line method that really ought to be decomposed into smaller, testable components.
So, what happens when some other poor schlep comes behind us to modify our code? They panic! The code is so convoluted and brittle they’re terrified their changes will break something far away. So, they insert just enough code to “make it work” while disrupting the code as little as possible. Instead of cleaning up the crappy code, they fling it even farther.
Finding and lowering the C. R. A. P. metric in your code
How do you stop the madness? Start by installing the Crap4j plug-in for Eclipse, load up one of your Java software projects, and click the button with the roll of toilet paper (did I already mention levity?)
Crap4j currently measures two important aspects of your code. The first is cyclomatic complexity – a measure of the independent paths through a method. A high complexity value indicates a method that is hard to understand and maintain.
The other aspect of your code that Crap4j measures is code coverage attained by executing the JUnit tests found in your projects. You do write JUnit tests, right? (You may answer anonymously). The value of a JUnit test is less about verifying the behavior of your code when you write it, and more about detecting changes in the behavior of your code when another part of the system changes. With adequate JUnit test coverage, you can be confident that changes made to one part of a legacy code base won’t break something elsewhere.
Complexity and coverage are combined in a formula to determine the CRAP metric. The higher the CRAP value on a method, the more you should consider refactoring it, adding test cases, or both. The poor soul left maintaining your code five years from now will thank you.
The plug-in will identify old Java code you may have forgotten about – code you had good intentions to revisit or write tests for but, in the rush of deliverables and deadlines, you just forgot about.
As I write this, Crap4j is less than a month old and unproven. The CRAP metric is versioned at 0.1, so be prepared for changes. It’s probably not wise for a team, at this point, to place too much emphasis on precise CRAP measures or establish a hard CRAP level as a coding standard. Nonetheless, even at this point, Crap4j highlights two important goals for reducing the cost of maintaining code in the future: reduce code complexity and write JUnit tests. Use CRAP measures as a guide to identify candidate methods most in need of attention.
So, what do you think? Have you tried the Crap4j plug-in? Am I right – or am I just full of crap?