Ruby Style Guide

The Ruby Style Guide

This Ruby style guide recommends best practices so that real-world Ruby programmers can write code that can be maintained by other real-world Ruby programmers. A style guide that reflects real-world usage gets used, and a style guide that holds to an ideal that has been rejected by the people it is supposed to help risks not getting used at all – no matter how good it is.

The guide is separated into several sections of related rules. We’ve tried to add the rationale behind the rules (if it’s omitted we’ve assumed that is pretty obvious).

The guidelines didn’t come out of nowhere. They are largely based on @bbatsov’s ruby-style-guide, modified according to the sober judgement and good taste of our senior engineers. The guide reflects feedback and suggestions from members of the Ruby community and various highly regarded Ruby programming resources, such as “Programming Ruby 1.9” and “The Ruby Programming Language”.

The guide is still a work in progress, and we strongly invite your feedback – guidelines to add, decisions you disagree with, illustrations of good or bad practice.

A foolish consistency is the hobgoblin of little minds – Ralph Waldo Emerson

This is a guide, not a rulebook. Break the rules with good taste, but not capriciously. For every one of the guidelines, there is a sound argument against it – otherwise we wouldn’t need to spell it out. Nobody needs a style guide to say “don’t write your documentation in pig latin”. Reasonable people can disagree whether drink = if > 19 then :beer else :soda end is clearer than drink = ( > 19) ? :beer : :soda1, but at infochimps we’ve settled on the second. Having one uniform choice carries more benefit than whatever fine distinction separates two close alternatives.

You can generate a PDF or an HTML copy of this guide using Transmuter.

Table of Contents

Source Code Layout

Nearly everybody is convinced that every style but their own is ugly and unreadable. Leave out the “but their own” and they’re probably right…
– Jerry Coffin (on indentation)


Good code is its own best documentation. As you’re about to add a comment, ask yourself, “How can I improve the code so that this comment isn’t needed?” Improve the code and then document it to make it even clearer.
– Steve McConnell

Internal comments


Ruby 1.9-only sugar

For all internal projects and most external projects we have abandoned ruby 1.8 compatibility. The exceptions are Wukong, all cookbooks, ironfan, configilere, and most of gorillib. Outside of those:


The only real difficulties in programming are cache invalidation and naming things.
– Phil Karlton … and off by one errors – apocryphal






Regular Expressions

Percent Literals


Use metaprogramming sparely. Metaprogramming should only occur in frameworks, not applications – it is justified to abstract a widely-repeated pattern of long use, and rarely otherwise.



  1. “Indeed, the authors of coffeescript outlawed the ternary (t ? a : b) operator”