.rubocop.yml

require:
  - rubocop-packaging
  - rubocop-performance
  - rubocop-rails
  - rubocop-rake
  - 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:
  # Generated files, like schema.rb, are out of our control.
  Exclude:
    - gemfiles/*
    - spec/dummy_app/db/schema.rb

  # Enable pending cops so we can adopt the code before they are switched on.
  NewCops: enable

  # See "Lowest supported ruby version" in CONTRIBUTING.md
  TargetRubyVersion: 3.0

Layout/ArgumentAlignment:
  EnforcedStyle: with_fixed_indentation

# This cop has a bug in 1.22.2 (https://github.com/rubocop/rubocop/issues/10210)
# When the bug is fixed, we'll return to using `EnforcedStyle: trailing`.
Layout/DotPosition:
  Enabled: false

# Avoid blank lines inside methods. They are a sign that the method is too big.
Layout/EmptyLineAfterGuardClause:
  Enabled: false

Layout/HeredocIndentation:
  Exclude:
    - paper_trail.gemspec

# The Ruby Style Guide recommends to "Limit lines to 80 characters."
# (https://github.com/bbatsov/ruby-style-guide#80-character-limits)
# Please aim for 80, but up to 100 is OK.
Layout/LineLength:
  Max: 100

Layout/MultilineMethodCallIndentation:
  EnforcedStyle: indented

Layout/MultilineOperationIndentation:
  EnforcedStyle: indented

Layout/ParameterAlignment:
  EnforcedStyle: with_fixed_indentation

# 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.
Layout/SpaceAroundOperators:
  AllowForAlignment: false

# Migrations often contain long up/down methods, and extracting smaller methods
# from these is of questionable value.
Metrics/AbcSize:
  Exclude:
    - 'spec/dummy_app/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 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

Naming/FileName:
  Exclude:
    - Appraisals

# Heredocs are usually assigned to a variable or constant, which already has a
# name, so naming the delimiter doesn't add much value unless doing so improves
# syntax highlighting. For example, all heredocs containing SQL should be named
# SQL, to support editor syntax highlighting.
Naming/HeredocDelimiterNaming:
  Enabled: false

Naming/PredicateName:
  AllowedMethods: has_paper_trail

# Too subtle to lint.
# Two-letter param names are OK. Consider `send_email(to:, cc:)`.
# Even one-letter names are OK. Consider `draw_point(x, y)`.
Naming/MethodParameterName:
  Enabled: false

# This cop has low value to begin with. Also, secondarily, it does not allow
# reasonable names like `rails_lt_6_0`.
Naming/VariableNumber:
  Enabled: false

# A valuable optimization in production code, but not valuable in specs.
Performance/CollectionLiteralInLoop:
  Exclude:
    - spec/**/*

# This cop only applies to app dev, not gem dev.
Rails/RakeEnvironment:
  Enabled: false

# Good advice for rails applications, but not applicable to libraries like PT.
Rails/SkipsModelValidations:
  Enabled: false

# This cop does not seem to work in rubocop-rspec 1.28.0
RSpec/DescribeClass:
  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

# 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

# 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

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

# Avoid annotated tokens except in desperately complicated format strings.
# In 99% of format strings they actually make it less readable.
Style/FormatStringToken:
  Enabled: false

Style/FrozenStringLiteralComment:
  Exclude:
    - gemfiles/* # generated by Appraisal

# 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

# `hash.keys.each` is totally fine.
Style/HashEachMethods:
  Enabled: false

# Only use postfix (modifier) conditionals for utterly simple statements.
# As a rule of thumb, the entire statement should not exceed 60 chars.
# Rubocop used to support this level of configuration, but no longer does.
Style/IfUnlessModifier:
  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/paper-trail-gem/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'

# Too subtle to lint. Use `format` for multiple variables. For single variables,
# use either interpolation or concatenation, whichever is easier to read.
Style/StringConcatenation:
  Enabled: false

# 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