194 lines
6.1 KiB
YAML
194 lines
6.1 KiB
YAML
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: 2.7
|
|
|
|
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/**/*
|
|
|
|
# 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
|