AllCops:
  Include:
    - Rakefile
    - Gemfile
    - '*.gemspec'

# I like this Metric in principle, but I don't like the default max of
# 15.
#
# Also, as per Metrics/ClassLength IMO this kind of limit should not
# apply to test code (I get up to 318 over there).
#
Metrics/AbcSize:
  Max: 100
  Exclude:
    - 'test/**/*.rb'

# Broadly speaking, test code gets a pass for most of the Metrics family.
#
# IMO test code is not the place get pedantic about class length,
# method complexity, etc.  One should be encouraged to add more tests
# with minimal friction, not forced to make a hard choice between
# cutting tests or splitting up my test suites.
#
Metrics/BlockLength:
  Exclude:
    - 'test/**/*.rb'

# Ditto I believe in more permissive rules in test code.
#
Metrics/ClassLength:
  Max: 400
  Exclude:
    - 'test/**/*.rb'

# Redis::ScriptManager#eval_gently is indeed overly complex but I am
# happy with it until the next time something goes wrong.
#
# Also ditto I believe in more permissive rules in test code.
#
Metrics/CyclomaticComplexity:
  Max: 30
  Exclude:
    - 'test/**/*.rb'
Metrics/MethodLength:
  Max: 100
  Exclude:
    - 'test/**/*.rb'
Metrics/PerceivedComplexity:
  Max: 21
  Exclude:
    - 'test/**/*.rb'

# I put extra spaces in a lot of expressions for a lot of different
# reasons, including especially readability.
#
# I reject these cops.
#
Layout:
  Enabled: false

# I like a lot of the Lint tests, but not these.
#
Lint/AmbiguousBlockAssociation:           # obnoxiously rejects idiomatic Ruby
  Enabled: false

# This does no more than insist I type "format" instead of "sprintf",
# where the two are aliases.
#
Style/FormatString:
  Enabled: false

# This complains that:
#
#   if foo
#     foo.bar
#   end
#
# could instead be:
#
#   foo.bar if foo
#
# ...which I reject, not least because the former is a lot easier to
# fit into an 80 character line.
#
Style/GuardClause:
  Enabled: false

# There is nothing wrong with Ruby 1.9 Hash syntax.
#
Style/HashSyntax:
  Enabled: false

# No.  Indeed, postfix if can often drive a line over 80 columns wide.
#
Style/IfUnlessModifier:
  Enabled: false

# No.  There is nothing wrong with "if !foo".
#
# As far as I'm concerned, "unless" is in poor taste because it means
# I have to think in English in two different logical senses - and
# English is a poor language for logical senses.
#
Style/NegatedIf:
  Enabled: false

# No.
#
# I can catenate strings with + if I want to.  Indeed, it looks better
# in my editor.
#
Style/LineEndConcatenation:
  Enabled: false

# Too pedantic.
#
Style/NumericLiterals:
  Enabled: false

# This complains that:
#
#   raise RuntimeError, "foo"
#
# Does not need the RuntimeError because it is redundant.
#
# I do not accept a requirement not to be explicit.
#
Style/RedundantException:
  Enabled: false

# "Do not use semicolons to terminate expressions."
#
# That's great when I terminate a single-line expression with a
# redundant semicolo because I forget I'm not using C.
#
# But when I'm using a semicolon to separate two expressions there is
# no other choice.  So this really ought to be Style/OneExprPerLine,
# which I reject.
#
Style/Semicolon:
  Enabled: false

# No.
#
# Some lines must have '\"'.  It is ugly to use a mix of '"' and '\''
# in LoCs which are close to one another.  Therefore, banning '"' if
# '"' is not strictly necessary drives visual inconsistency.
#
Style/StringLiterals:
  Enabled: false

# This is the same kind of obnoxious pedantry which drove Hungarian
# Notation.
#
# The [] literal syntax is perfectly servicable and there is no point
# _tightly_ coupling it to the content of the array.  That's why we
# have context-free grammers!
#
Style/SymbolArray:
  Enabled: false

# Shockingly, this cop requires us to *OMIT*, not *INCLUDE* parens in
# ternery conditons.
#
# IMO this one is actively harmful in that it discourages attention to
# clarity and avoiding some nasty precedence surprises.
#
Style/TernaryParentheses:
  Enabled: false

# I am a huge fan of using trailing commas when I break an argument
# list down one-per line.
#
# As such, I reject this test.
#
Style/TrailingCommaInLiteral:
  Enabled: false

# No.  attr_writer, attr_reader, etc. are strictly optional.
#
# If I want to use the longer, less sugary form that is my business.
#
# I especially believe this where, for instance, I have a trivial
# reader but a non-trivial writer.  I want consistency between them -
# which would be prohibited by this requirement.
Style/TrivialAccessors:
  Enabled: false

# Too pedantic.  I am starting to think I should switch from "opt out"
# to "opt in" on the Style family.
#
Style/WordArray:
  Enabled: false
Style/YodaCondition:
  Enabled: false
Style/ZeroLengthPredicate:
  Enabled: false