Cane: failing your build for code quality problems

February 13, 2012

Code review and pairing are great techniques to keep code quality high, but they are expensive. Automated tools are not.

The cheapest method for detecting certain classes of problem—method complexity, whitespace issues, missing documentation, missing code coverage—is automation. No one should be distracted by these problems by the time the code gets to review.

Ruby 1.8.7 had a number of tools in this category: flog, flay, reek, metricfu to aggregate them, and many more. Unfortunately, for 1.9 the pickings have been much slimmer. We also wanted an integrated tool that would easily allow us to run many types of checks and fail our builds for any violations.

Enter Cane.

gem install cane

It provides a report that looks like this:

> cane
Methods exceeded maximum allowed ABC complexity (2):

  lib/cane.rb  Cane > sample    23
  lib/cane.rb  Cane > sample_2  17

Lines violated style requirements (2):

  lib/cane.rb:20   Line length >80
  lib/cane.rb:42   Trailing whitespace

Classes are not documented (1):
  lib/cane:3  SomeClass

Also, it returns a non-zero exit code. The thresholds can be adjusted, and if you don't like any of the checks you can turn them off.

Automated tools like this often get a bad reputation for creating busy work by flagging too many false negatives. Cane takes a deliberately light touch to avoid this problem.

The greatest benefit of cane is that it is a powerful anti-stupidity check. "You're about to check in the most complicated method on the project. Are you sure?" More often than not, the answer is "no". If "yes", do not be afraid to up your thresholds. Remember: cane is a means, not an end.

Cane has helped us increase our quality across the team, but I also have found it incredibly helpful to keep me honest when coding by myself.

Try it out and let us know how it works for you.

Xavier Shay
Platform Engineer @xshay

Comments

Get support help at squareup.com/support. We'll delete off-topic comments.