I’ve been thinking about the code review process recently. It’s a great way to get a second opinion on your code, while also spreading knowledge of how the code works within your organization. In particular, I’ve become a fan of the approach to code reviews advocated by Alex Gaynor. Alex suggests looking at code at four levels:
In this post, I want to focus on that last question: Does the code adhere to style guides and best practices? From my experience, this step of a review can take the longest, though in reality much of that work can be automated. In fact, the developer requesting a review can check that issues of style and good practice before the review begins. When writing Ruby code, a tool I’ve started using more is Pronto.
Pronto works by comparing your commit(s) to the Git branch you’d like to merge them into. For the developer, it lists any issues it finds in your code so that you can address them. For the reviewer, it provides a list of potential issues the original developer may have missed. Pronto assumes you’re using Git, and works well if your team uses pull requests as part of your merging approach.
Actually, Pronto itself doesn’t do the checking. A series of add-on runners do. Here are my favorites, so far:
You can install them by adding them to the
:development group in your
project’s Gemfile, or via
gem install. One aside: On my Mac, I had to install
cmake via Homebrew.
Of course, the tools themselves aren’t new. If you’ve been developing Ruby for awhile you’ve probably come across some or all of them. Yet, it can be easy to forget to run them on your changes. That’s what makes Pronto so useful. Before pushing your changes, run Pronto on them. For example, if I want my change to be merged into master, I’d compare it like this:
$ pronto run -c origin/master
If any of the runners find issues, Pronto will report them. You can then do any remaining cleanup, then push your branch and open a pull request. I use Pronto in this manner to compare local changes, but you may want to configure it to interact directly with GitHub or GitLab, and post comments directly on the offending commit or pull request. I’ll let you review Pronto’s README for more on how to do that.
Is it perfect? Not always. Sometimes one of the runners will raise a false alarm. Other times it may miss something entirely. In those cases, you’ll need a human to intervene. More often than not, though, they work pretty well–or, if nothing else, help you think about your code one last time before opening that pull request.
If you liked my series on practical advice for adding reliable tests to your Rails apps, check out the expanded ebook version. Lots of additional, exclusive content and a complete sample Rails application.
Ruby on Rails news and tips, and other ideas and surprises from Aaron at Everyday Rails. Delivered to your inbox on no particular set schedule.