Archive for the ‘metrics’ Category

JRuby Code Quality

Lots of people think that they are the best coders in the world, or that there is absolutely nothing to improve in a codebase for a particular gem, plugin or library. Until you put your code to the test, you have no metrics from which to base your claim upon. Smarticus just pointed me at a set of tools I can use to put my money where my mouth is, or to at least bring us all back down to reality. We all have code that is stellar, but portions of that code might just be facades to ugly procedural spaghetti.

In order to get your code back into shape, you might need help from a small set of tools to point you in the right direction. This is especially true in medium to large codebases, where wandering around aimlessly in the code sniffing out code smells might lead to a wasted effort. Time is a precious commodity, so you should want to spend it as efficiently as possible. Not to mention, it will make the process a lot more fun.

Three tools I find very useful are flog, flay and roodie.

flog (Ruby Sadist)
Flog shows you the worst, most painful code to test, read or maintain.
You’ll get a higher score the more painful your code is to look at.

In order to run flog on all your code. Try this:

find lib -name \*.rb | xargs flog

You might be amazed at what you find. Bryan Liles ( recently mentioned in a conference that nobody gets 0-10, and most of his team’s code is 10-20. 20-50 should be refactored. Above 50 should be rewritten. Lucky for me, mine started out at 9.9, but I still had some improvements to make, and I’ve been able to improve it to 9.3. Normally I don’t brag, but Bryan kind of antagonized me. 😉  This was also run in a complex codebase, where the goal of the project is to come up with auto-generated trades based on analyzing up to 30 years of stock history.  Not a simple problem to solve by any means, but rewarding when it works and you know it is designed correctly.

Flay does a great job of analyzing ruby code for structural similarities.
If you’re on board with the Ruby way, you’ll want to keep your code DRY.
Flay will report back to you a set of code that is a good candidate for refactoring.

 sudo gem install flay
 flay lib/*.rb

Roodi measures cyclomatic complexity (CC = E – N + P).

E represents the number of edges on a graph.
N would be the number of nodes, and
P is the number of connected components.

Each conditional decision point in a method is counted. Another is added for the method’s entry point, resulting in an measurement denoting a method’s complexity.

The art and science of code metrics can be a very useful way to keep your code organized, simple to follow and DRY. It is important to remember that code metrics are not a goal, they are an aspiration. Even if you have fantastic metrics, but the code does nothing useful, you just have a big ball of code that nobody’s interested in. I would recommend to stay pragmatic, and use the results of your metrics as a guide in your journey.