Skip to content

janlelis/relaxed.ruby.style

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

44 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Version 2.5

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.

Motivation

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

How to Read this Style Guide

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).

Usage

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

Style/Alias

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

Style/AsciiComments

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.

Style/BeginBlock

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

Style/BlockDelimiters

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

Style/CommentAnnotation

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

Style/Documentation

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

Layout/DotPosition

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.

Style/DoubleNegation

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

Style/EndBlock

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

Style/FormatString

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

Style/IfUnlessModifier

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

Style/Lambda

Disabled rule. It does not matter if you use ->(){} or lambda{} to create lambdas.

Style/ModuleFunction

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

Style/MultilineBlockChain

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

Style/NegatedIf

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.

Style/NegatedWhile

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

Style/NumericPredicate

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.

Style/ParallelAssignment

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

Style/PercentLiteralDelimiters

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

Style/PerlBackrefs

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

Style/Semicolon

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

Style/SignalException

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

Style/SingleLineBlockParams

(Dropped from RuboCop style guide). Don't give your block parameters bad names.

Style/SingleLineMethods

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.

Layout/SpaceBeforeBlockBraces

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

Layout/SpaceInsideParens

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

Style/SpecialGlobalVars

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

Style/StringLiterals

Disabled rule. Deliberately use single or double quoted strings!

Style/TrailingCommaInArguments

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.

Style/SymbolArray

Disabled rule. You can use the %i syntax for an array of symbols, but usage of an array of symbols is fine, too.

Style/TrailingCommaInLiteral

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.

Style/WordArray

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.

Style/WhileUntilModifier

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

Lint/AmbiguousRegexpLiteral

Use regex normally.

Lint/AssignmentInCondition

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

Metrics

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

Other Ruby Style Guides

Find more at ruby.style

Taking this Style Guide Forward

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.

Also See