AllCops:
  TargetRubyVersion: 2.7.0
  # We choose to opt-in to new checks by default. This allows us to update
  # version by version without having to worry about adding an entry for each
  # new "enabled by default" check. If we want to jump multiple versions and
  # wish to be notified of all the enw check, then we'll need to change
  # `NewCops` to `pending.
  NewCops: enable
  Exclude:
    # Exclude generated binstubs
    - 'bin/bundle'
    - 'bin/bundler-travis'
    - 'bin/pronto'
    - 'bin/pry'
    - 'bin/radius-cli'
    - 'bin/rake'
    - 'bin/rspec'
    - 'bin/rubocop'
    - 'bin/travis'
    - 'bin/webpack'
    - 'bin/webpack-dev-server'
    - 'bin/yard'
    - 'bin/yarn'
    # Exclude vendored content
    - 'vendor/**/*'

# We prefer outdented access modifiers as we feel they provide demarcation of
# the class similar to `rescue` and `ensure` in a method.
#
# Configuration parameters: EnforcedStyle, IndentationWidth.
# SupportedStyles: outdent, indent
Layout/AccessModifierIndentation:
  Details: |

    Prefer outdented access modifiers to provide demarcation of the class
    similar to `rescue` and `ensure` in a method.
  EnforcedStyle: outdent

# Rubocop 0.60.0 changed how it handled value alignments in this cop. This
# breaks our preference for wanting keys to be aligned, but allowing values to
# either use the `key` or `table` style:
#
#     key_style = {
#       key: :value,
#       another: :value,
#       yet_another: :value
#     }
#     table_style = {
#       key:         :value,
#       another:     :value
#       yet_another: :value
#     }
#
# This is logged with Rubocop: https://github.com/rubocop-hq/rubocop/issues/6410
#
# Until Rubocop resolves this we've decided to enforce the key style so that we
# do not lose all associated formatting checks. Additionally, in response to
# the referenced issue the Rubocop disables the alignment check by default. To
# continue using it we force enable it here.
#
# Configuration parameters: EnforcedHashRocketStyle, EnforcedColonStyle, EnforcedLastArgumentHashStyle.
# SupportedHashRocketStyles: key, separator, table
# SupportedColonStyles: key, separator, table
# SupportedLastArgumentHashStyles: always_inspect, always_ignore, ignore_implicit, ignore_explicit
Layout/HashAlignment:
  Enabled: true
  EnforcedHashRocketStyle: key
  EnforcedColonStyle: key

# Disabling this until it is fixed to support multi-line block chains using the
# semantic style.
#
# See https://github.com/bbatsov/rubocop/issues/5655
#
# Configuration parameters: EnforcedStyleAlignWith.
# SupportedStylesAlignWith: either, start_of_block, start_of_line
Layout/BlockAlignment:
  Enabled: false

# Disabling this until it is fixed to handle multi-line method chains where the
# first method call is multi-line.
#
# See https://github.com/bbatsov/rubocop/issues/5650
#
# Configuration parameters: EnforcedStyle, IndentationWidth.
# SupportedStyles: consistent, consistent_relative_to_receiver,
#                  special_for_inner_method_call, special_for_inner_method_call_in_parentheses
#
# TODO: At some point this is split into both Layout/FirstArgumentIndentation
# and Layout/FirstParameterIndentation
Layout/FirstArgumentIndentation:
  Enabled: false

# This project only uses newer Ruby versions which all support the "squiggly"
# style. We prefer to use pure Ruby calls when possible instead of relying on
# alternatives; even for Rails app.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: auto_detection, squiggly, active_support, powerpack, unindent
Layout/HeredocIndentation:
  EnforcedStyle: squiggly

# We generally prefer to use the default line length of 80. Though sometimes
# we just need a little extra space because it makes it easier to read.
#
# The only way to disable Rubocop for a single line is either to wrap the line
# with two comments or append the disable comment to the end of the line. For
# guard clauses, we tend to prefer trailing comments to avoid adding two lines
# just to disable a cop on one line.
#
# Sometimes comments include ASCII diagrams, flow charts, etc. These cannot
# always be reformatted to fit within the 80 column limit. Also, we write most
# comments in markdown format. Rubocop isn't very good at understanding when
# the line is long because of a URL in a markdown link. Instead of requiring
# additional comments to turn this cop off for comments we ignore any long
# lines which are only comments.
#
# There are also cases where for one valid reason or another we have a trailing
# comment that extends a little too far. We'd like to be able to ignore those
# as well. This _attempts_ to do that, however, as this uses simple regular
# expressions we can only attempt to match so much. We probably should change
# this for a node pattern matcher in the future.
#
# Configuration parameters: AllowHeredoc, AllowURI, URISchemes,
#                           IgnoreCopDirectives, IgnoredPatterns.
# URISchemes: http, https
Layout/LineLength:
  IgnoreCopDirectives: true
  IgnoredPatterns:
    # Leading comments
    - '\A\s*#'
    # Attempt at trailing comments
    - '\A.{1,78}\s#\s.*\z'
  Max: 100
  Exclude:
    - '**/*.gemspec'

# We tend to indent multi-line operation statements. I think this is because it
# tends to be the default style auto-formatted by VIM (which many of us use).
# It also helps show the continuation of the statement instead of it
# potentially blending in with the start of the next statement.
#
# Configuration parameters: EnforcedStyle, IndentationWidth.
# SupportedStyles: aligned, indented
Layout/MultilineOperationIndentation:
  Details: "This helps show expression continuation setting it apart from the following LOC."
  EnforcedStyle: indented

# In our specs Rubocop inconsistently complains when using the block form of
# `expect` and `change`. It accepts code when a method is chained onto
# `change`, but otherwise it complains. Since this is a widely used pattern in
# our specs we just tell Rubocop to ignore our spec files.
#
#     # Acceptable to Rubocop
#     expect {
#       some_action
#     }.to change {
#       object.state
#     }.from(:original).to(:updated)
#
#     # Rubocop complains
#     expect {
#       some_action
#     }.to change {
#       object.state
#     }
Lint/AmbiguousBlockAssociation:
  Exclude:
    - 'spec/**/*_spec.rb'

# We prefer to enforce a consistent usage for readability
#
#     <<~SQL.strip
#       bar
#     SQL
#
#     display(<<~SQL.strip)
#       bar
#     SQL
#
# Alternatively, refactoring the heredoc into a local also improves
# readability:
#
#     custom_sql = <<~SQL
#       bar
#     SQL
#     display(custom_sql.strip)
Lint/HeredocMethodCallPosition:
  Enabled: true

# We prefer people suggesting people subclass `StandardError` for their custom
# exceptions as this is a relatively common Ruby idiom.
Lint/InheritException:
  EnforcedStyle: standard_error

# Often with benchmarking we don't explicitly "use" a variable or return value.
# We simply need to perform the operation which generates said value for the
# benchmark.
#
# Configuration parameters: CheckForMethodsWithNoSideEffects.
Lint/Void:
  Exclude:
    - 'benchmarks/**/*'

Metrics/AbcSize:
  # TODO: When we are able to upgrade to Rubocop 1.5.0 we want to enable the
  # following `CountRepeatedAttributes` option. We often find the
  # multi-references to the same object to be necessary for reability and that
  # for our team it does not increase complexity.
  #
  # CountRepeatedAttributes: false
  Max: 17

# Configuration parameters: CountComments, ExcludedMethods, Max.
# ExcludedMethods: refine
Metrics/BlockLength:
  Exclude:
    - '**/Rakefile'
    - '**/*.rake'
    - 'spec/spec_helper.rb'
    - 'spec/**/*_spec.rb'
    - 'spec/support/model_factories.rb'
  ExcludedMethods:
    - 'chdir'
    - 'refine'
    - 'Capybara.register_driver'
    - 'RSpec.configure'
    - 'VCR.configure'

# TODO: Remove this when we get to 0.89.0 as the new default max is 8
#
# Configuration parameters: IgnoredMethods, Max
Metrics/PerceivedComplexity:
  Max: 8

# This is overly pedantic (only allowing `other` as the parameter name). Ruby
# core doesn't follow this consistently either. Looking at several classes
# throughout Ruby core we do often see `other`, but also often `obj` or
# `other_*`. In some cases, the parameter is named more meaningfully with names
# like `real`, `numeric`, or `str`.
Naming/BinaryOperatorParameterName:
  Enabled: false

# Configuration parameters: ExpectMatchingDefinition, Regex, IgnoreExecutableScripts, AllowedAcronyms.
# AllowedAcronyms: CLI, DSL, ACL, API, ASCII, CPU, CSS, DNS, EOF, GUID, HTML, HTTP, HTTPS, ID, IP, JSON, LHS, QPS, RAM, RHS, RPC, SLA, SMTP, SQL, SSH, TCP, TLS, TTL, UDP, UI, UID, UUID, URI, URL, UTF8, VM, XML, XMPP, XSRF, XSS
Naming/FileName:
  Exclude:
    - '**/Gemfile'
    - '**/*.gemspec'
    - '**/Brewfile'

# This allows `EOF` as the only `EO*` variant.
#
# `EOF` is a common terminal abbreviate indicating end-of-file. We allow this
# for those heredocs which represent "file" text.
#
# Configuration parameters: ForbiddenDelimiters.
# ForbiddenDelimiters: (?-mix:(^|\s)(EO[A-Z]{1}|END)(\s|$))
Naming/HeredocDelimiterNaming:
  Details: |

    Use meaningful delimiter names to provide context to the text. The only
    allowed `EO*` variant if `EOF` which has specific meaning for file content.
  ForbiddenDelimiters:
    - !ruby/regexp '/(^|\s)(EO[A-EG-Z]{1}|END)(\s|$)/'

# It is generally a good idea to match the instance variable names with their
# methods to keep consistent with the attribute reader / writer pattern.
# However, this can pose an issue in Rails. Most notably, when writing modules
# that will be used as controller plugins. The reason is that the Rails
# controllers-to-view interface is ivars. Using a leading underscore can help
# avoid accidental controller ivar naming conflicts.
#
# Configuration parameters: EnforcedStyleForLeadingUnderscores.
# SupportedStylesForLeadingUnderscores: disallowed, required, optional
Naming/MemoizedInstanceVariableName:
  Details: |

    It is generally a good idea to match the instance variable names with their
    methods to keep consistent with the attribute reader / writer pattern. An
    exception can be made for modules that want to avoid naming conflicts with
    classes that include them. In this case a single leading underscore is
    acceptable.
  EnforcedStyleForLeadingUnderscores: optional

# We don't really care about this check. Sometimes using something simple such
# as `err` is just fine. Other times it may improve readability to have a more
# descriptive name. We feel this is a personal judgement call and not something
# that needs to be enforced.
Naming/RescuedExceptionsVariableName:
  Enabled: false

# `alias` behavior changes on scope. In general we expect the behavior to be
# that which is defined by `alias_method`.
#
# See https://stackoverflow.com/questions/4763121/should-i-use-alias-or-alias-method
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: prefer_alias, prefer_alias_method
Style/Alias:
  Details: |

    Prefer `alias_method` because `alias` behavior changes based on scope.

    See:
      - https://stackoverflow.com/questions/4763121/should-i-use-alias-or-alias-method
      - https://blog.bigbinary.com/2012/01/08/alias-vs-alias-method.html
  EnforcedStyle: prefer_alias_method

# Keeping with our semantic style we allow use of `and` / `or` conditionals
# when it is used for control flow:
#
#     system("some command") or system("another command")
#
# Used in this manner it provides additional semantic clues to the intent of
# the code. However, when there is a conditional, or the intent is to perform
# a boolean comparison, the `&&` / `||` style should be used.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: always, conditionals
Style/AndOr:
  Details: |

    Use `&&` / `||` for conditionals or general comparison. Use `and` / `or`
    for control flow to provide additional semantic hints:

        system("some command") or system("another command")
  EnforcedStyle: conditionals

# These days most people have editors which support unicode and other
# non-ASCII characters.
#
# Configuration parameters: AllowedChars.
Style/AsciiComments:
  Enabled: false

# Use semantic style for blocks:
#   - Prefer `do...end` over `{...}` for procedural blocks.
#   - Prefer `{...}` over `do...end` for functional blocks.
#
# When the return value of the method receiving the block is important prefer
# `{...}` over `do...end`.
#
# Some people enjoy the compact readability of `{...}` for one-liners so we
# allow that style as well.
#
# Configuration parameters: EnforcedStyle, ProceduralMethods, FunctionalMethods, IgnoredMethods.
# SupportedStyles: line_count_based, semantic, braces_for_chaining
Style/BlockDelimiters:
  Details: |

    Use semantic style for blocks:
      - Prefer `do...end` over `{...}` for procedural blocks.
      - Prefer `{...}` over `do...end` for functional blocks.

    When the return value of the method receiving the block is important prefer
    `{..}` over `do..end`.
  AllowBracesOnProceduralOneLiners: true
  Enabled: true
  EnforcedStyle: semantic
  ProceduralMethods:
    - benchmark
    - bm
    - bmbm
    - measure
    - realtime
    - with_object
  FunctionalMethods:
    - create
    - create!
    - build
    - build!
    - default_scope
    - each_with_object
    - filter_sensitive_data
    - find
    - git_source
    - let
    - let!
    - new
    - subject
    - tap
    - watch
  IgnoredMethods:
    - lambda
    - proc
    - it

# Prefer `Time` over `DateTime`.
#
# While these are not necessarily interchangeable we prefer `Time`. According
# to the Ruby docs `DateTime` is meant more for historical dates; it also does
# not consider leap seconds or summer time rules.
#
# Lastly, `DateTime` is part of the stdlib which is written in Ruby; where as
# `Time` is part of core and written in C.
#
# Configuration parameters: AllowCoercion
Style/DateTime:
  Enabled: true

# The double negation idiom is a common Ruby-ism. All languages have various
# idioms and part of learning the language is learning the common idioms. Once
# learning the meaning it is not cryptic as Rubocop implies.
#
#   > Double negation converts converts a value to boolean.
#   >
#   > It converts "truthy" values to `true` and "falsey" values, `nil` and
#   > `false`, to `false`.
#
# The [Rubocop style guide](https://github.com/rubocop-hq/ruby-style-guide#no-bang-bang)
# does have a valid complaint about it's use in a conditional:
#
#   > you don't need this explicit conversion in the condition of a control
#   > expression; using it only obscures your intention...
#   >
#   > ```ruby
#   > # bad
#   > x = 'test'
#   > # obscure nil check
#   > if !!x
#   >   # body omitted
#   > end
#   >
#   > # good
#   > x = 'test'
#   > if x
#   >   # body omitted
#   > end
#   > ```
#
# This is true and we completely agree. However the check isn't limited to just
# conditional control expressions. It affects any use of the idiom.
#
# We believe using the idiom is completely valid for predicate methods to
# ensure either a `true` or `false` return, instead of just a "truthy" or
# "falsey" response. As it is an op it is a bit faster than the alternative of
# sending `nil?` to the object and more concise than using `obj == nil`. It
# also works with something that is potentially `false` as expected.
#
# As we cannot customize this to only limit it to the conditional control
# expressions, or instances which may be better replaced with something else
# (like `blank?`), we are disabling it.
Style/DoubleNegation:
  Enabled: false

# Using `case` instead of an `if` expression when the case condition is empty
# can be more expressive of intent. Using multiple "cases" informs the reader
# that all of the conditions are related or coupled in a meaningful way.
# Multi-branch `if` expressions do not necessarily convey this relation. They
# may simply be separate branching logic and possibly only flattened for
# readability.
Style/EmptyCaseCondition:
  Enabled: false

# Always write methods on multiple lines.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: compact, expanded
Style/EmptyMethod:
  EnforcedStyle: expanded

# Always require the pragma comment to be true
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: always, always_true, never
Style/FrozenStringLiteralComment:
  EnforcedStyle: always_true

# Prefer symbol keys using the 1.9 hash syntax. However, when keys are mixed
# use a consistent mapping style; which generally means using hash rockets:
#
#     # bad
#     {:a => 2}
#     {b: 1, :c => 2}
#     {d: 1, 'e' => 2}
#
#     # good
#     {a: 2, b: 1}
#     {:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
#
# Configuration parameters: EnforcedStyle, UseHashRocketsWithSymbolValues, PreferHashRocketsForNonAlnumEndingSymbols.
# SupportedStyles: ruby19, hash_rockets, no_mixed_keys, ruby19_no_mixed_keys
Style/HashSyntax:
  Details: |

    Prefer symbol keys using the 1.9 hash syntax. However, when keys are mixed
    use a consistent mapping style; which generally means using hash rockets.
  EnforcedStyle: ruby19_no_mixed_keys

# As part of our semantic style we generally use the literal `-> { }` format to
# indicate this is a function with a return value we care about. As this cop
# doesn't have a more flexible setting we prefer the literal syntax to the
# lambda version.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: line_count_dependent, lambda, literal
Style/Lambda:
  Details: |

    As part of our semantic style we generally use the literal `-> { }` format
    to indicate this is a function with a return value we care about. As this
    cop doesn't have a more flexible setting we prefer the literal syntax to
    the lambda version.
  EnforcedStyle: literal

# Avoid chaining a method call on a do...end block. This breaks semantic style
# reducing contextual information.
Style/MethodCalledOnDoEndBlock:
  Details: "This breaks semantic style reducing contextual information."
  Enabled: true

# With semantic style (functional blocks) it's common to chain several methods
# to avoid creating multiple intermediate local variables. Block length is
# generally not an issue here as these types of usage tend to produce short (<
# 5 LOC) multi-line blocks.
Style/MultilineBlockChain:
  Enabled: false

# Context for this cop is too dependent.
#
# Often using the numeric comparison is faster. Also, depending on the context
# a numeric comparison may produce a more consistent style:
#
#     # numeric comparison is more natural and consistent
#     if n < 0
#     elsif n < 5
#     elsif n < 20
#     end
#
# Configuration parameters: AutoCorrect, EnforcedStyle.
# SupportedStyles: predicate, comparison
Style/NumericPredicate:
  Enabled: false

# In Ruby every method returns a value. Implicitly this is the value of the
# last line of the method. This means using `return` is often redundant.
# However, there isn't anything inherently wrong about doing so. In fact, in
# some cases it can help with a consistent style in a method:
#
#     def transform(value)
#       return value.call if value.is_a?(Proc)
#       return value if value.frozen?
#       return value.dup
#     end
#
# Other times it can add context to a seemingly oddly place value:
#
#     def munge(data)
#       data.slice! 5
#       return nil
#     end
#
# We often omit the explicit `return` in our code. Though sometimes we include
# it for improved contextual clues and we don't want Rubocop to complain for
# those cases.
#
# Configuration parameters: AllowMultipleReturnValues.
Style/RedundantReturn:
  Enabled: false

# Prefer slashes for simple expressions. For multi-line use percent literal
# to support comments and other advanced features. By using the mixed style we
# are choosing to use `%r{}` for multi-line regexps. In general we are not a
# fan of single vs multi-line dictating a style. We do make an exception in
# this case because of the parity the braces give to general code block
# grouping:
#
#     regex = %r{
#       foo
#       (bar)
#       (baz)
#     }x
#
# Configuration parameters: EnforcedStyle, AllowInnerSlashes.
# SupportedStyles: slashes, percent_r, mixed
Style/RegexpLiteral:
  Details: |

    Prefer slashes for simple expressions. Use `%r` for expressions containing
    slashes and for complex expressions so then can be written across multiple
    lines (allowing advanced features such as comments). Use of `%r` for
    expressions spanning multiple lines provides some comprehension parity with
    general code blocks.
  EnforcedStyle: mixed

# If you only need to rescue a single, or predefined set of exceptions, then
# catch the exceptions explicitly. However, when you need to include a general
# error handler / "catch-all" use the "unspecified rescue".
#
# Using the unspecified `rescue` on blocks is common Ruby practice. It is a
# core feature of the language which has semantic meaning. The Rubocop docs do
# not provide much justification for defaulting to an explicit style and there
# is no real mention of this in the associated style guide except the following
# buried in an example for [_Avoid rescuing the `Exception`
# class_](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues) though
# the anchor suggests this is for "no blind rescues":
#
# > # a blind rescue rescues from StandardError, not Exception as many
# > # programmers assume.
#
# Our general rule for Ruby exceptions is to create your custom errors from
# `StandardError`. Creating custom errors off of `Exception` is reserved for
# special edge cases where you don't intend for someone to normally catch it
# (such as system resource issues; e.g. `NoMemoryError`, `SecurityError`).
#
# With that in mind, we can make the same counter argument that since
# programmers generally assume the unspecified rescue rescues `Exception`,
# which they normally should not be rescuing, system errors are more likely to
# noticed.
#
# Additionally, use of the unspecified rescue looks and behaves like a
# "catch-all" or the `else` clause in a `case` statement:
#
#   begin
#     # do something that may cause a standard error
#   rescue TypeError
#     handle_type_error
#   rescue => e
#     handle_error e
#   end
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: implicit, explicit
Style/RescueStandardError:
  Details: |

    If you only need to rescue a single, or predefined set of exceptions, then
    catch each exception explicitly. When you need to include a general error
    handler or "catch-all" use the "unspecified rescue":

        begin
          # do something that may cause a standard error
        rescue TypeError
          handle_type_error
        rescue => e
          handle_error e
        end

    Avoid rescuing `Exception` as this may hide system errors.
  EnforcedStyle: implicit

# We generally prefer double quotes but many generators use single quotes. We
# don't view the performance difference to be all that much so we don't care
# if the style is mixed or double quotes are used for static strings.
#
# Configuration parameters: EnforcedStyle, ConsistentQuotesInMultiline.
# SupportedStyles: single_quotes, double_quotes
Style/StringLiterals:
  Enabled: false

# As with regular string literals we have no real preference for this. Forcing
# one style of strings over others for this case just adds to Rubocop noise and
# in our experience developer frustration.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: single_quotes, double_quotes
Style/StringLiteralsInInterpolation:
  Enabled: false

# We don't feel too strongly about percent vs bracket array style. We tend to
# use the percent style, which also happens to be Rubocop's default. So for
# pedantic consistency we'll enforce this.
#
# However, as we don't feel that strongly about this we'll increase the
# minimum size to 3 to allow very small arrays to exist either way.
#
# Configuration parameters: EnforcedStyle, MinSize.
# SupportedStyles: percent, brackets
Style/SymbolArray:
  MinSize: 3

# When ternaries become complex they can be difficult to read due to increased
# cognitive load parsing the expression. Cognitive load can increase further
# when assignment is involved.
#
# Configuration parameters: EnforcedStyle, AllowSafeAssignment.
# SupportedStyles: require_parentheses, require_no_parentheses, require_parentheses_when_complex
Style/TernaryParentheses:
  AllowSafeAssignment: false
  Details: |

    When ternaries become complex they can be difficult to read due to
    increased cognitive load parsing the expression. Cognitive load can
    increase further when assignment is involved. To help reduce this cognitive
    use parentheses for complex expressions.
  EnforcedStyle: require_parentheses_when_complex

# Always use trailing commas for multiline. This makes git diffs easier to read
# by cutting down on noise when commas are appended.
#
# However, specs often multi-line `expect()` for readability with long lines.
# We don't want to enforce a trailing comma in that case. Ideally, there would
# be another option to only enforce a consistent comma when there is more than
# one argument.
#
# Configuration parameters: EnforcedStyleForMultiline.
# SupportedStylesForMultiline: comma, consistent_comma, no_comma
Style/TrailingCommaInArguments:
  Details: |

    Always use trailing commas for multiline arguments. This makes git diffs
    easier to read by cutting down on noise when commas are appended. It also
    simplifies adding, removing, and swapping argument orders.
  EnforcedStyleForMultiline: consistent_comma
  Exclude:
    - 'spec/**/*_spec.rb'

# Always use trailing commas for multiline. This makes git diffs easier to read
# by cutting down on noise when commas are appended.
#
# Configuration parameters: EnforcedStyleForMultiline.
# SupportedStylesForMultiline: comma, consistent_comma, no_comma
Style/TrailingCommaInArrayLiteral:
  Details: |

    Always use trailing commas for multiline arrays. This makes git diffs
    easier to read by cutting down on noise when commas are appended. It also
    simplifies adding, removing, and re-arranging the elements.
  EnforcedStyleForMultiline: consistent_comma

# Always use trailing commas for multiline. This makes git diffs easier to read
# by cutting down on noise when commas are appended.
#
# Configuration parameters: EnforcedStyleForMultiline.
# SupportedStylesForMultiline: comma, consistent_comma, no_comma
Style/TrailingCommaInHashLiteral:
  Details: |

    Always use trailing commas for multiline hashes. This makes git diffs
    easier to read by cutting down on noise when commas are appended. It also
    simplifies adding, removing, and re-arranging the elements.
  EnforcedStyleForMultiline: consistent_comma

# We don't feel too strongly about percent vs bracket array style. We tend to
# use the percent style, which also happens to be Rubocop's default. So for
# pedantic consistency we'll enforce this.
#
# However, as we don't feel that strongly about this we'll increase the
# minimum size to 3 to allow very small arrays to exist either way.
#
# Configuration parameters: EnforcedStyle, MinSize, WordRegex.
# SupportedStyles: percent, brackets
Style/WordArray:
  MinSize: 3

# When it comes to constants it's safer to place the constant on the right-hand
# side. With a constant accidental assignment will produce a syntax error.
#
# Configuration parameters: EnforcedStyle.
# SupportedStyles: all_comparison_operators, equality_operators_only
Style/YodaCondition:
  Enabled: false