litany against fear

coding with spice ¤ by nick quaranto

RailsConf 2009 Automated Code Quality Checking in Ruby and Rails

published 07 May 2009

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Marty Andrews.

Plenty of ways to lower your WTFs/minute when looking at code. Static analysis = just looking at the code without running it. Why do this though? There’s plenty of practices that already enforce quality: testing, pair programming, etc…but there’s much more that you can do on your own.

Code smells are important, you need to really follow your nose. Plenty of tools are available to help with this:

Rails stats, which comes packaged with the framework: rake stats. It gives plenty of metrics, but what is most important is the Code to Test Ratio. This is most useful for human review and communicating with your team that you need to test more.

Reek: searches for code smells. There’s plenty of things this gem searches for, such as dupliation, long methods, uncommunicative names, control coupling, and the list goes on and on. Showing off how to use the command and what it prints out. Reek is best for regular human review and checking your own code.

Flog: complexity checking of Ruby code. It checks your methods for how complex they are, and warns you when they’re getting out of hand through a scoring system. Methods with high scores should probably be refactored. You can use flog to enforce code quality at the level of continuous integration: builds don’t pass if the flog scores are too high.

Flay: is a pretty complex tool that finds duplicate or similarly structured code. This gem can find potential candidates for refactoring. This can also be used in automation, since it has a score as well. Same concept: if the score is over a threshold, fail the build.

Roodi: checks for design problems, which involves checking plenty of different code qualities. Basically prints out different problems with your code. One big thing it checks is cyclomatic complexity, which goes higher for the number of branches and loops in a method. It’s the minimum amount of tests you need for a piece of code, so refactoring it so it’s lower is better. Another neat thing is that it looks for = in conditionals. Using Roodi in automation is great since it allows you to tweak the settings that are appropriate for your project, for example the level of cyclomatic complexity that is acceptable.

Metric-fu: reports on all of the above in one neat package with rake metrics:all. It also includes some other great reports, such as Churn. Churn will show you what files have changed the most often in your source code repo, which means that you might want to split it up. This is best for regular human review.

In your CI: flog, flay, roodi.
For yourself and your team: metric_fu, rails stats, reek (and more!)



code (2) gaming (3) git (9) internet (5) prorubyconf (25) railsconf (17) ruby (10) windows (3)