The Devver Blog

A Boulder startup improving the way developers work.

Revisiting additional Ruby Tools

I have heard about new Ruby tools since I did my Ruby Tools Roundup. I am always interested in tools that can help improve our code, so I had to check some of them out. Similar to my last tools post, I will be trying out a tool and writing my general impressions along with the basic usage.


I have to start with reek, since it has been the most requested and searched on our site since I originally wrote about tools. reek will help identify code smells, allowing you to fix up your code. Instead of looking at cyclomatic complexity or other metrics, reek looks at patterns to warn you about bad code. Reek currently detects a few code smells (Long Method, Large Class, Feature Envy, Uncommunicative Name, Long Parameter List, Utility Function, Nested Iterators, Control Couple, Duplication) but more are on the way.

I think this project is useful but would need to be more customized before a nightly run would yield very useful results. The biggest problem I have is the signal to noise ratio seemed pretty high. Reek was warning me about “long methods” that were only 7 statements long, which just isn’t something I am concerned about. The warnings on duplicate methods calls can be useful, after running reek on a few files I found a couple places where duplicate method calls were wasting time. Many of the other smells are interesting like ‘Feature Envy’, and ‘Utility Function’. I will need to use reek more before I know if these smells are good indicators or often false positives.

Below reek finds a utility function next_tick which is definitely a helper function that actually exists in two of our files, which probably should be moved into a helper mixin.

def next_tick
      EM.next_tick do

I am really looking forward to see how the tool progresses. If the project allows for a simple config customization to change the thresholds as well as ignore some files/smells, this could become a very useful tool to help keep a team maintain a high expectation of code quality. It would be useful to get nightly reports about any code that might not meet expectations, so a quick group code review could decide if it is an exception (which can be quickly added to the config) or if the code should be refactored and cleaned up.

dmayer$ sudo gem install reek
dmayer$ reek ./lib/client/client.rb
[Utility Function] Client#next_tick doesn't depend on instance state
[Long Method] Client#process_done has approx 7 statements
[Duplication] Client#process_ready calls @buffer.create_reload_msg more than once
[Long Method] Client#process_ready has approx 10 statements
[Duplication] Client#report_system_message calls result.msg more than once
[Feature Envy] Client#report_system_message refers to result more than self
[Duplication] Client#send_tests calls more than once
[Long Method] Client#send_tests has approx 24 statements
[Feature Envy] Client#send_tests refers to tests more than self
#check a whole directory
dmayer$ reek ./lib/client/*


Towelie helps discover duplication in Ruby code, it will help keep your code DRY. It doesn’t have a nice interface at the moment and it is pretty young code. That being said, it can still be a really useful tool to help guide refactoring and code cleanup.

~/projects dmayer$ git clone git://
dmayer$ cd ~/projects/devver/
dmayer$ irb -r ~/projects/towelie/lib/towelie.rb
irb(main):001:0> @t =
=> #, @model=#>
irb(main):002:0> @t.parse "lib/client"
(string):24: warning: useless use of a variable in void context
=> nil
irb(main):003:0> puts @t.duplicates
found in:

def nl

... 2 more dupes in the reporters ...

found in:

def report(str)

found in:

def quit

found in:

def send_quit

=> nil

There are currently many duplications because we are maintaining two clients while deciding what route to eventually take. We have also moved a lot of our shared client code into a mixin, and Towelie finds some methods that really should be moved there as well such as the methods “quit” and “send_quit”, which is currently duped in 4 files. Towelie also points to the fact that we should refactor our reporters because they both duplicate code.

I have always been annoyed with copied and pasted functions accidentally working its way in code, this could be a useful nightly run to keep a team DRY. Sometimes two team members implement the same functionality without even knowing a solution already exists in the code base. If you want to go a bit more in depth, check out Giles Bowkett’s (creator of Towelie) How to use Towelie


Flay is another great tool by Ryan Davis who also works on Heckle and Flog which I covered in the past. Flay, like Towelie, helps keep your code DRY, it detects exact and similar code throughout a project. It seems to be more powerful than Towelie, as seen in this Towelie and Flay comparison. My biggest complaint is the current release has some pretty basic output that you see below. The output I got from Towelie was immediately more recognizable and useful, while Flay currently requires you to dig in a bit deeper on your own into its suggestions. An improvement is already being worked on and a verbose output mode should be in the release soon. Once better output is included I think Flay will be immediately useful out of the box even with small amounts of developer effort.

I like that Flay has weight system, which should make it easy to set some threshold to ignore, high level weights are more likely to be worth your time and attention. One piece of code Flay tagged with a low weight was code that rescued and logged different errors thrown, which while similar actually served a purpose.

rescue Errno::EISDIR => ed
      @stderr.puts "Error: #{ed.message}" if @stderr
      @stderr.puts "You can't pass a directory to devver only test files. Quitting." if @stderr
    rescue LoadError => le
      @stderr.puts "Error: #{le.message}" if @stderr
      @stderr.puts "Not all of the files can be found. Quitting." if @stderr
    rescue SyntaxError, NameError => se
      @stderr.puts "Error: #{se.message}" if @stderr
      @stderr.puts "This file doesn't appear to be a valid Ruby file. Quitting." if @stderr

Digging into the Flay results turned up some duplicate code that Towelie had missed. Since Towelie also caught a method that was duped in 4 client files that Flay missed (I was expecting Towelie’s results to be a subset of what Flay found), perhaps there is room for both of the tools and learning to work with both a little bit is worth the time. After a little bit of work perhaps one of the projects will become a clearly better option. Until then I will be following both of these projects.

sudo gem install flay
dmayer$ flay lib/client/*.rb
Processing lib/client/client.rb...
Processing lib/client/mod_client.rb...
Processing lib/client/syncer.rb...

Matches found in :defn (mass = 84)

Matches found in :block (mass = 57)

... 6 more results ...

Matches found in :if (mass = 34)

Matches found in :defn (mass = 32)


That should cover it for this Ruby tools post, but I am really enjoying checking out the tools showing up in the Ruby scene. So as always let me know if I missed something, or if there is a tool you would like to see a full write up on. After some of the tools mature a little bit I will have to revisit a few of the tools which are currently in the early stages. I hope the Ruby tools scene keeps as active as it has been lately because there are some interesting projects being worked on.

honorable mentions (things I didn’t think really needed a full write up)

  • metric-fu a great gem to give quick access to a bunch of tools and metrics about your code (RCov, Saikuro, Flog, SCM Churn, and Rails Stats)
  • CruiseControl.rb when you start using all of these tools, continuous integration starts to become more important (or doing nightly runs). CruiseControl.rb is dead simple continuous integration.
  • Simian another code duplication tool, which is mentioned in 3 tools for drying your Ruby code (free for OSS, $99 for a license)
  • Ruby Tidy a tool for cleaning up HTML (I haven’t used this in Ruby, but loved the Java version in my Java days)
  • Watir is an open-source library for automating web browsers. It allows you to write tests that are easy to read and maintain. It is simple and flexible.
  • Autotest, if you haven’t heard of autotest, check it out, continuously run your tests every time you save a file in your project.
  • Rufus a tool that checks if code you are about to load is safe. Allows you to look for custom patterns that you don’t want to run.
  • I wrote about a couple benchmarking tools last time and here is a great article / tutorial on Ruby benchmarking

Written by DanM

December 3, 2008 at 10:01 am

One Response

Subscribe to comments with RSS.

  1. Hi Dan, thanks for the thoughtful review of reek! Its algorithms are definitely still in the "experimental" stage, as the version number of 0.3.x indicates. There's lots to come in the next few months, including some configurability and less "noise" in the reports.

    If you're reading this and you've tried reek, please stick with it as it improves, and help me improve it by telling me what it gets wrong? Oh, and watch for updates!
    Regards, Kevin

    Kevin Rutherford

    December 4, 2008 at 12:33 am

Comments are closed.

%d bloggers like this: