Software metrics (and tools) for Rails projects (part 2)


In the previous part of this article we’ve seen how to install metric_fu plugin and started playing with Churn, Flog and Flay. In this part we’ll explore Reek, Roodi, Saikuro, Stats and Rcov.

Ok, let’s continue!


Reek - by Kevin Rutherford - is another tool that analyzes the code and tells us if and when common “bad” patterns happean, or in other words “code stinks”:

Let’s see what happeans on your project after using that metric tool:

$ rake metrics:reek


Roodi stands for “Ruby Object Oriented Design Inferometer”. It’s a tool that does some checks on our code:

After modifying our app/models/post.rb with these lines:

class Post < ActiveRecord::Base
  def approval_process(post_body)
      if (post_body =~ /bad word/)
      # what to do here?

Hitting a rake metrics:roodi reports that:

Definitely an useful weapon!


In a recent post I’ve wrote a little about cyclomatic complexity, that is what precisely Saikuro takes care of (“saikuron” from japanes means “cyclon”).

Cyclomatic complexity is a useful metric to use, without doubt.


The most simple tool, and a default presence in Rails is the Rake stats command:

$ rake stats        # or metrics:stats

Although simple, it’s a great tool: in one shoot we can have a broad vision of our project.


Another topic often discussed is related to code coverage: how many tests we should write in order to have enough confidence on our code?

Well, first we should concentrate on code with high cyclomatic complexity and then we should look at code not yet covered by tests.

Code coverage in metric_fu is done by Rcov gem. There are three distinct types of code coverage:

Rcov can handle only C0 type, that offers no guarantees but at least can tell us which lines of codes were executed.

Take a look at the summary obtained by issuing rake metrics:coverage:

Clicking on a file path we can see exactly the lines of code executed:


We have seen some tips on using metrics in our Rails project. As everything that we “measure” we should be careful in the amount of confidence we put in it, but don’t forget that - at least - we have some useful insights on our projects.


blog comments powered by Disqus