A more liberal style guide for RuboCop. It comes with a config file that deactivates some of RuboCop's features. It is meant as a less restrictive foundation that you can use directly or base your style discussions on.

RuboCop is an amazing tool, still some of its default rules feel overly strict. This might distract you from the helpful messages.

Warning: Does include opinionated style advice.

This is not a stand-alone style guide, but a patch applied to bbatsov/ruby-style-guide (the style guide RuboCop is based on).

Use, copy or inherit from rubocop.yml.

Disabled rule. Feel free to use the alias keyword when appropriate.

Disabled rule. Use BEGIN blocks when it makes sense.

Disabled rule. Consider using {} for multi-line blocks.

Document your code and/or write a good ReadMe. And good specs. Choose descriptive method and variable names!

Disabled rule. When chaining methods on multiple lines, it is a good idea to put the dots at the end of the lines to indicate that the expression continues on the next line.

Disabled rule. Use !!variable to get the boolean value of a variable.

Disabled rule. Use END blocks or `Kernel#at_exit' for code that should be executed when the program quits.

Disabled rule. Creating format string can be done using the String#% method.

Disabled rule. Use or don't use if/unless in modifier style whenever you think it improves code readability.

Disabled rule. Use ->(){} or lambda{} to create lambdas.

Disabled rule. Prefer extend self over module_function. It uses Ruby's inheritance chain, instead of copying all methods. Less magic! More Info

Disabled rule. Chain multiple blocks when it makes sense, this promotes a functional programming mindset.

Disabled rule. Always use if !condition for complex conditions with negations. For simple conditions, for which it also unlikely that an else clause will be added at some later point, it is also OK to use unless condition.

Disabled rule. Always use while !condition for complex conditions with negations. For simple conditions, it is also OK to use until condition.

Disabled rule. Parallel assignment can sometimes express the intented logic better than sequential assignment. It is also faster.

Disabled rule. When creating literals with the % syntax, choose any delimiters that don't interfere with the literal's content.

Disabled rule. It is fine to use the special local variables $1 - $9 to access the contents of your last matched regex groups.

Disabled rule. Usage of semicolons to separate multiple statements is OK.

Disabled rule. You are free to choose if you want to raise exceptions with raise or fail.

Disabled rule. Don't give your block parameters bad names.

Disabled rule. Single-line methods can be useful for short getter- or setter-like methods, when attr_reader / attr_accessor / attr_writer are not enough anymore.

It is not important if there is a space between a method call and a passed block.

Disabled rule. Avoid putting spaces inside parentheses, but do it when it improves readability. For example, when using RSpec's expect method.

Disabled rule. Refering to two-letter version of special global variables is OK, although not very polite.

Disabled rule. Deliberately use single or double quoted strings!

Disabled rule. Use trailing commas in multi-line literals. It makes manipulating the literal easier (reordering, appending, removing) and leads to smaller git diffs. Consider using RuboCop's EnforcedStyleForMultiline: consistent_comma option.

Disabled rule. Use or don't use while/until in modifier style whenever you think it improves code readability.

Use regex normally.

Disabled rule. Use = for assignments in conditions. Use == for comparisons in conditions.

RuboCop's code complexity metrics can be very useful indications, however, they should be discussed, tweaked and activated individually.

• This Guide
• Ruby Style Guide (Rubocop)

• Christian Neukirchen
• Fast Ruby
• Ruby Style Guide (Rubocop)
  • GitHub
  • Airbnb