.rubocop.yml

require:
  - rubocop-rspec

inherit_from: .rubocop_todo.yml

# Please:
#
# - Comment any deviations from the Ruby Style Guide
# - Alphabetize cops
# - Only include permanent config; temporary goes in .rubocop_todo.yml

AllCops:
  Exclude:
    - gemfiles/vendor/bundle/**/* # This dir only shows up on travis ¯\_(ツ)_/¯
    - test/dummy/db/schema.rb # Generated, out of our control

  # Set to lowest supported version
  TargetRubyVersion: 2.1

# Migrations often contain long up/down methods, and extracting smaller methods
# from these is of questionable value.
Metrics/AbcSize:
  Exclude:
    - 'test/dummy/db/migrate/*'

# Not a useful metric compared to, e.g. `AbcSize`.
Metrics/BlockLength:
  Enabled: false

# Not a useful metric compared to, e.g. `AbcSize`.
Metrics/ClassLength:
  Enabled: false

# The Ruby Style Guide recommends to "Limit lines to 80 characters."
# (https://github.com/bbatsov/ruby-style-guide#80-character-limits)
# but 100 is also reasonable.
Metrics/LineLength:
  Max: 100

# The number of lines in a method is not a useful metric compared to `AbcSize`.
# It's common to have very long methods (> 50 lines) which are quite simple. For
# example, a method that returns a long string with only a few interpolations.
Metrics/MethodLength:
  Enabled: false

# Not a useful metric compared to, e.g. `AbcSize`.
Metrics/ModuleLength:
  Enabled: false

# In an ideal world, each example has a single expectation. In the real world,
# sometimes setup is a pain and you don't want to duplicate setup in multiple
# examples, or make the specs more confusing with many nested `context`s, and
# the practical thing is to have multiple expectations.
RSpec/MultipleExpectations:
  Enabled: false

# Yes, ideally examples would be short. Is it possible to pick a limit and say,
# "no example will ever be longer than this"? Hard to say. Sometimes they're
# quite long.
RSpec/ExampleLength:
  Enabled: false

Style/AlignParameters:
  EnforcedStyle: with_fixed_indentation

# Please use semantic style, e.g. `do` when there's a side-effect, else `{}`.
# The semantic style is too nuanced to lint, so the cop is disabled.
Style/BlockDelimiters:
  Enabled: false

Style/DotPosition:
  EnforcedStyle: trailing

# Use double negation wherever it would otherwise be impractical to convert
# a value to an actual boolean.
Style/DoubleNegation:
  Enabled: false

Style/FileName:
  Exclude:
    - Appraisals

# The decision of when to use a guard clause to improve readability is subtle,
# and it's not clear that it can be linted. Certainly, the default
# `MinBodyLength` of 1 can actually hurt readability.
Style/GuardClause:
  Enabled: false

# Use postfix (modifier) conditionals for one-liners, unless doing so would
# exceed 60 characters.
Style/IfUnlessModifier:
  MaxLineLength: 60

Style/IndentHeredoc:
  Exclude:
    - paper_trail.gemspec

# The Ruby Style Guide says:
#
# > Use \ instead of + or << to concatenate two string literals at line end.
#
# but in my experience the `\` style is rarely used and less readable. Please
# concatenate multiline strings with `+` or use a HEREDOC.
Style/LineEndConcatenation:
  Enabled: false

# Using `module_function` instead of `extend self` would make the instance
# methods in these modules private. That would be a breaking change, so these
# modules are excluded. See discussion in:
# - https://github.com/airblade/paper_trail/pull/756
# - https://github.com/bbatsov/ruby-style-guide/issues/556
Style/ModuleFunction:
  Exclude:
    - 'lib/paper_trail/serializers/json.rb'
    - 'lib/paper_trail/serializers/yaml.rb'

Style/MultilineMethodCallIndentation:
  EnforcedStyle: indented

Style/MultilineOperationIndentation:
  EnforcedStyle: indented

Style/PredicateName:
  NameWhitelist: has_paper_trail

# The Ruby Style Guide does not prescribe a particular quote character, only
# that a project should pick one and be consistent. The decision has no
# performance implications. Double quotes are slightly easier to read.
Style/StringLiterals:
  EnforcedStyle: double_quotes

# Use exactly one space on each side of an operator. Do not align operators
# because it makes the code harder to edit, and makes lines unnecessarily long.
Style/SpaceAroundOperators:
  AllowForAlignment: false