mirror of
https://github.com/meineerde/rackstash.git
synced 2025-10-17 14:01:01 +00:00
Holger Just
8db2c917c2
All of these changes are either simple formatting changes or clarify existing meaning. None of these changes affects externally visible behavior.
105 lines
2.8 KiB
YAML
105 lines
2.8 KiB
YAML
AllCops:
|
|
TargetRubyVersion: 2.1
|
|
|
|
# We use a different style where we add the short license header just below the
|
|
# magic comments separated by an empty comment line. Unfortunately, this cop
|
|
# clashes with our style
|
|
Layout/EmptyLineAfterMagicComment:
|
|
Enabled: false
|
|
|
|
Layout/MultilineMethodCallIndentation:
|
|
EnforcedStyle: indented
|
|
|
|
# Multiline indentation is always tricky. Format it as deemed useful in the
|
|
# local method, but try to avoid it at all wherever possible
|
|
Layout/MultilineOperationIndentation:
|
|
Enabled: false
|
|
|
|
# Sometimes we want to capture all exceptions. We need to make sure to re-raise
|
|
# these again in any case.
|
|
Lint/RescueException:
|
|
Enabled: false
|
|
|
|
# As long as methods and classes are readable, this should be fine.
|
|
# In any case, this shouldn't be a hard error. We try to improve where sensible
|
|
# using tools like RubyCritic instead
|
|
Metrics/AbcSize:
|
|
Enabled: false
|
|
Metrics/CyclomaticComplexity:
|
|
Enabled: false
|
|
Metrics/PerceivedComplexity:
|
|
Enabled: false
|
|
|
|
# Long classes and methods are not a problem per se, as long as it is kept kind
|
|
# of sane. In any case, this shouldn't be a hard error..
|
|
Metrics/ClassLength:
|
|
Enabled: false
|
|
Metrics/MethodLength:
|
|
Enabled: false
|
|
|
|
# rspec uses long blocks by definition
|
|
Metrics/BlockLength:
|
|
Exclude:
|
|
- 'spec/**/*'
|
|
|
|
# Try to keep lines below 80 chars wherever possible though
|
|
Metrics/LineLength:
|
|
AllowURI: true
|
|
Max: 100
|
|
|
|
# We use a semantic style with do...end for procedual blocks and { ... } for
|
|
# functional blocks. Unfortunately, it's often not clear from a simple code
|
|
# analysis, which kind we ought to use. Use common sense in this case :)
|
|
Style/BlockDelimiters:
|
|
Enabled: false
|
|
|
|
Style/Copyright:
|
|
Enabled: true
|
|
Notice: '^# Copyright (\(c\) )?2[0-9]{3} .+'
|
|
|
|
# Use === when it makes sense to do so
|
|
Style/CaseEquality:
|
|
Enabled: false
|
|
|
|
# Both styles (i.e. assigning the return falue of a conditional once or
|
|
# assigning explicitly inside the conditional) have their place, dependent on
|
|
# the complexity. Enforcing a single style doesn't make the code any clearer.
|
|
Style/ConditionalAssignment:
|
|
Enabled: false
|
|
|
|
# Double negation is fine to reliably produce a Boolean from any value.
|
|
Style/DoubleNegation:
|
|
Enabled: false
|
|
|
|
Style/EmptyMethod:
|
|
EnforcedStyle: expanded
|
|
|
|
Style/PercentLiteralDelimiters:
|
|
PreferredDelimiters:
|
|
'%w': '[]'
|
|
'%i': '[]'
|
|
|
|
# Sometimes, an explicit self really adds some clarity to the code
|
|
# We make sure to not use it when not needed though
|
|
Style/RedundantSelf:
|
|
Enabled: false
|
|
|
|
# Doesn't work with Refinements and is sometimes clearer with the expanded
|
|
# version
|
|
Style/SymbolProc:
|
|
Enabled: false
|
|
|
|
Style/RegexpLiteral:
|
|
Exclude:
|
|
- 'spec/**/*'
|
|
|
|
# We know what we are doing and only use the rescue modifier when we really
|
|
# don't care
|
|
Style/RescueModifier:
|
|
Enabled: false
|
|
|
|
# Use %w when it makes sense. Use literal arrays where it is more clear.
|
|
Style/WordArray:
|
|
Enabled: false
|
|
|