* Use soft-tabs with a two space indent.

<a name="default-indentation"></a>^{[[link](#default-indentation)]}

* Indent `when` with the start of the `case` expression.

<a name="indent-when-as-start-of-case"></a>^{[[link](#indent-when-as-start-of-case)]}

``` ruby

* Never leave trailing whitespace.

<a name="trailing-whitespace"></a><sup>[[link](#trailing-whitespace)]</sup>

* Use spaces around operators, after commas, colons and semicolons, around `{`

and before `}`.

<a name="spaces-operators"></a><sup>[[link](#spaces-operators)]</sup>

``` ruby

sum = 1 + 2

* No spaces after `(`, `[` or before `]`, `)`.

<a name="no-spaces-braces"></a><sup>[[link](#no-spaces-braces)]</sup>

``` ruby

some(arg).other

* No spaces after `!`.

<a name="no-spaces-bang"></a><sup>[[link](#no-spaces-bang)]</sup>

``` ruby

!array.include?(element)

* End each file with a [newline](https://github.com/bbatsov/ruby-style-guide#newline-eof).

<a name="newline-eof"></a><sup>[[link](#newline-eof)]</sup>

* Use empty lines between `def`s and to break up a method into logical

paragraphs.

<a name="empty-lines-def"></a><sup>[[link](#empty-lines-def)]</sup>

``` ruby

def some_method

* Keep each line of code to a readable length. Unless you have a reason to, keep lines to a maximum of 118 characters. Why 118? That's the width at which the pull request diff UI needs horizontal scrolling (making pull requests harder to review).

<a name="line-length"></a><sup>[[link](#line-length)]</sup>

* Avoid the usage of class (`@@`) variables due to their unusual behavior

in inheritance.

<a name="class-variables"></a><sup>[[link](#class-variables)]</sup>

``` ruby

class Parent

* Use `def self.method` to define singleton methods. This makes the methods

more resistant to refactoring changes.

<a name="singleton-methods"></a><sup>[[link](#singleton-methods)]</sup>

``` ruby

class TestClass

* Avoid `class << self` except when necessary, e.g. single accessors and aliased

attributes.

<a name="class-method-definitions"></a><sup>[[link](#class-method-definitions)]</sup>

``` ruby

class TestClass

* Indent the `public`, `protected`, and `private` methods as much the

method definitions they apply to. Leave one blank line above them.

<a name="access-modifier-identation"></a><sup>[[link](#access-modifier-identation)]</sup>

``` ruby

class SomeClass

* Avoid explicit use of `self` as the recipient of internal class or instance

messages unless to specify a method shadowed by a variable.

<a name="self-messages"></a><sup>[[link](#self-messages)]</sup>

``` ruby

class SomeClass

* Prefer `%w` to the literal array syntax when you need an array of

strings.

<a name="percent-w"></a><sup>[[link](#percent-w)]</sup>

``` ruby

* Use symbols instead of strings as hash keys.

<a name="symbols-as-keys"></a><sup>[[link](#symbols-as-keys)]</sup>

``` ruby

Avoid calling `send` and its cousins unless you really need it. Metaprogramming can be extremely powerful, but in most cases you can write code that captures your meaning by being explicit:

<a name="avoid-send"></a><sup>[[link](#avoid-send)]</sup>

``` ruby

unless [:base, :head].include?(base_or_head)

raise ArgumentError, "base_or_head must be either :base or :head"

Use the Ruby 1.9 syntax for hash literals when all the keys are symbols:

<a name="symbols-as-hash-keys"></a><sup>[[link](#symbols-as-hash-keys)]</sup>

``` ruby

If you have a hash with mixed key types, use the legacy hashrocket style to avoid mixing styles within the same hash:

<a name="consistent-hash-syntax"></a><sup>[[link](#consistent-hash-syntax)]</sup>

``` ruby

[Keyword arguments](http://magazine.rubyist.net/?Ruby200SpecialEn-kwarg) are recommended but not required when a method's arguments may otherwise be opaque or non-obvious when called. Additionally, prefer them over the old "Hash as pseudo-named args" style from pre-2.0 ruby.

* Prefer string interpolation instead of string concatenation:

<a name="string-interpolation"></a><sup>[[link](#string-interpolation)]</sup>

``` ruby

will always work without a delimiter change, and `'` is a lot more

common than `"` in string literals.

<a name="double-quotes"></a><sup>[[link](#double-quotes)]</sup>

``` ruby

* Use `def` with parentheses when there are arguments. Omit the

parentheses when the method doesn't accept any arguments.

<a name="method-parens-when-arguments"></a><sup>[[link](#method-parens-when-arguments)]</sup>

``` ruby

def some_method

always use parentheses in the method invocation. For example, write

`f((3 + 2) + 1)`.

<a name="parens-no-spaces"></a><sup>[[link](#parens-no-spaces)]</sup>

* Never put a space between a method name and the opening parenthesis.

<a name="no-spaces-method-parens"></a><sup>[[link](#no-spaces-method-parens)]</sup>

``` ruby

* Never use `then` for multi-line `if/unless`.

<a name="no-then-for-multi-line-if-unless"></a><sup>[[link](#no-then-for-multi-line-if-unless)]</sup>

``` ruby

* The `and` and `or` keywords are banned. It's just not worth it. Always use `&&` and `||` instead.

<a name="no-and-or-or"></a><sup>[[link](#no-and-or-or)]</sup>

* Favor modifier `if/unless` usage when you have a single-line

body.

<a name="favor-modifier-if-unless"></a><sup>[[link](#favor-modifier-if-unless)]</sup>

``` ruby

* Never use `unless` with `else`. Rewrite these with the positive case first.

<a name="no-else-with-unless"></a><sup>[[link](#no-else-with-unless)]</sup>

``` ruby

* Don't use parentheses around the condition of an `if/unless/while`.

<a name="no-parens-if-unless-while"></a><sup>[[link](#no-parens-if-unless-while)]</sup>

``` ruby

trivial. However, do use the ternary operator(`?:`) over `if/then/else/end` constructs

for single line conditionals.

<a name="trivial-ternary"></a><sup>[[link](#trivial-ternary)]</sup>

``` ruby

* Avoid multi-line `?:` (the ternary operator), use `if/unless` instead.

<a name="no-multiline-ternary"></a><sup>[[link](#no-multiline-ternary)]</sup>

* Use one expression per branch in a ternary operator. This

also means that ternary operators must not be nested. Prefer

`if/else` constructs in these cases.

<a name="one-expression-per-branch"></a><sup>[[link](#one-expression-per-branch)]</sup>

``` ruby

doesn't introduce a new scope (unlike `each`) and variables defined

in its block will be visible outside it.

<a name="avoid-for"></a><sup>[[link](#avoid-for)]</sup>

``` ruby

arr = [1, 2, 3]

definitions" (e.g. in Rakefiles and certain DSLs). Avoid `do...end`

when chaining.

<a name="squiggly-braces"></a><sup>[[link](#squiggly-braces)]</sup>

``` ruby

names = ["Bozhidar", "Steve", "Sarah"]

* Some will argue that multiline chaining would look OK with the use of `{...}`,

contents be extracted into nifty methods?

* Avoid `return` where not required.

<a name="avoid-return"></a><sup>[[link](#avoid-return)]</sup>

``` ruby

* Use spaces around the `=` operator when assigning default values to method parameters:

<a name="spaces-around-equals"></a><sup>[[link](#spaces-around-equals)]</sup>

``` ruby

* Use `||=` freely to initialize variables.

<a name="memoization-for-initialization"></a><sup>[[link](#memoize-away)]</sup>

``` ruby

* Don't use `||=` to initialize boolean variables. (Consider what

would happen if the current value happened to be `false`.)

<a name="no-memoization-for-boolean"></a><sup>[[link](#no-memoization-for-boolean)]</sup>

``` ruby

one-liner scripts is discouraged. Prefer long form versions such as

`$PROGRAM_NAME`.

<a name="no-cryptic-vars"></a><sup>[[link](#no-cryptic-vars)]</sup>

* Use `_` for unused block parameters.

<a name="underscore-unused-vars"></a><sup>[[link](#underscore-unused-vars)]</sup>

``` ruby

For example, `String === "hi"` is true and `"hi" === String` is false.

Instead, use `is_a?` or `kind_of?` if you must.

<a name="type-checking-is-a-kind-of"></a><sup>[[link](#type-checking-is-a-kind-of)]</sup>

Refactoring is even better. It's worth looking hard at any code that explicitly checks types.