Cane: failing your build for code quality problems
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.
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.