A more liberal style guide for RuboCop. It comes with a config file which 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.
This is not a stand-alone style guide, but a patch applied to rubocop-hq/ruby-style-guide (the style guide RuboCop is based on).
Use, copy or inherit from rubocop.yml.
One way is to add the following lines to your .rubocop.yml:
inherit_from:
- https://relaxed.ruby.style/rubocop.yml
You could also get the styleguide via rubygems. Add to your Gemfile:
gem "relaxed-rubocop"
And in your .rubocop.yml:
inherit_gem:
relaxed-rubocop: .rubocop.yml
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.
Numprical predicates (like x.negative?) can be used when it improves code readability,
but using explicit comparisons (like x < 0) is good, too.
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. You can use the
%i syntax for an array of symbols, but usage of an array of symbols is fine, too.
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.
Find more at ruby.style
If you like this style guide and have an idea how to improve it, feel free to create an issue or pull request. Please create an extra issue per RuboCop rule that you want to see changed so that it can be merged or rejected individually.