Relaxed Ruby Style

Version 2.2

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.

How to Read this Style Guide

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 Cops & Relaxed Style Recommendations


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


You are free to use your source encoding in code comments. For example, if your source encoding is UTF-8, you can use UTF-8 characters in comments.


Disabled rule. Use BEGIN blocks when you need its functionality.


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


Disabled rule. It is totally optional to put a colon and a space behind TODOs and FIXMEs


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 should 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. It does not matter if you 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.


(Dropped from RuboCop style guide). You are free to choose if you want to raise exceptions with raise or fail.


(Dropped from RuboCop style guide). 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 argument lists. It makes manipulating the params easier (reordering, appending, removing) and leads to smaller git diffs. Consider using RuboCop's EnforcedStyleForMultiline: consistent_comma option.


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.


Word arrays using the percent syntax make for a good and concise way to create an array of strings, especially if creating lots of strings. However, it it should be considered a good option, instead of being mandatory to use.


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.

Other Ruby Style Guides

Also See

Fork me on GitHub