This cop checks that the ABC size of methods is not higher than the configured maximum. The ABC size is based on assignments, branches (method calls), and conditions. See http://c2.com/cgi/wiki?AbcMetric

This cop checks if the length of a method exceeds some maximum value. Comment lines can optionally be ignored. The maximum allowed length is configurable.

This cop checks if the length of a method exceeds some maximum value. Comment lines can optionally be ignored. The maximum allowed length is configurable.

Feature Envy occurs when a code fragment references another object more often than it references itself, or when several clients do the same series of manipulations on a particular type of object.

Feature Envy reduces the code's ability to communicate intent: code that "belongs" on one class but which is located in another can be hard to find, and may upset the "System of Names" in the host class.

Feature Envy also affects the design's flexibility: A code fragment that is in the wrong class creates couplings that may not be natural within the application's domain, and creates a loss of cohesion in the unwilling host class.

Feature Envy often arises because it must manipulate other objects (usually its arguments) to get them into a useful form, and one force preventing them (the arguments) doing this themselves is that the common knowledge lives outside the arguments, or the arguments are of too basic a type to justify extending that type. Therefore there must be something which 'knows' about the contents or purposes of the arguments. That thing would have to be more than just a basic type, because the basic types are either containers which don't know about their contents, or they are single objects which can't capture their relationship with their fellows of the same type. So, this thing with the extra knowledge should be reified into a class, and the utility method will most likely belong there.

Example

Running Reek on:

class Warehouse
  def sale_price(item)
    (item.price - item.rebate) * @vat
  end
end

would report:

Warehouse#total_price refers to item more than self (FeatureEnvy)

since this:

(item.price - item.rebate)

belongs to the Item class, not the Warehouse.

A method with Too Many Statements is any method that has a large number of lines.

Too Many Statements warns about any method that has more than 5 statements. Reek's smell detector for Too Many Statements counts +1 for every simple statement in a method and +1 for every statement within a control structure (if, else, case, when, for, while, until, begin, rescue) but it doesn't count the control structure itself.

So the following method would score +6 in Reek's statement-counting algorithm:

def parse(arg, argv, &error)
  if !(val = arg) and (argv.empty? or /\A-/ =~ (val = argv[0]))
    return nil, block, nil                                         # +1
  end
  opt = (val = parse_arg(val, &error))[1]                          # +2
  val = conv_arg(*val)                                             # +3
  if opt and !arg
    argv.shift                                                     # +4
  else
    val[0] = nil                                                   # +5
  end
  val                                                              # +6
end

(You might argue that the two assigments within the first @if@ should count as statements, and that perhaps the nested assignment should count as +2.)

Feature Envy occurs when a code fragment references another object more often than it references itself, or when several clients do the same series of manipulations on a particular type of object.

Feature Envy reduces the code's ability to communicate intent: code that "belongs" on one class but which is located in another can be hard to find, and may upset the "System of Names" in the host class.

Feature Envy also affects the design's flexibility: A code fragment that is in the wrong class creates couplings that may not be natural within the application's domain, and creates a loss of cohesion in the unwilling host class.

Feature Envy often arises because it must manipulate other objects (usually its arguments) to get them into a useful form, and one force preventing them (the arguments) doing this themselves is that the common knowledge lives outside the arguments, or the arguments are of too basic a type to justify extending that type. Therefore there must be something which 'knows' about the contents or purposes of the arguments. That thing would have to be more than just a basic type, because the basic types are either containers which don't know about their contents, or they are single objects which can't capture their relationship with their fellows of the same type. So, this thing with the extra knowledge should be reified into a class, and the utility method will most likely belong there.

Example

Running Reek on:

class Warehouse
  def sale_price(item)
    (item.price - item.rebate) * @vat
  end
end

would report:

Warehouse#total_price refers to item more than self (FeatureEnvy)

since this:

(item.price - item.rebate)

belongs to the Item class, not the Warehouse.

Feature Envy occurs when a code fragment references another object more often than it references itself, or when several clients do the same series of manipulations on a particular type of object.

Feature Envy reduces the code's ability to communicate intent: code that "belongs" on one class but which is located in another can be hard to find, and may upset the "System of Names" in the host class.

Feature Envy also affects the design's flexibility: A code fragment that is in the wrong class creates couplings that may not be natural within the application's domain, and creates a loss of cohesion in the unwilling host class.

Feature Envy often arises because it must manipulate other objects (usually its arguments) to get them into a useful form, and one force preventing them (the arguments) doing this themselves is that the common knowledge lives outside the arguments, or the arguments are of too basic a type to justify extending that type. Therefore there must be something which 'knows' about the contents or purposes of the arguments. That thing would have to be more than just a basic type, because the basic types are either containers which don't know about their contents, or they are single objects which can't capture their relationship with their fellows of the same type. So, this thing with the extra knowledge should be reified into a class, and the utility method will most likely belong there.

Example

Running Reek on:

class Warehouse
  def sale_price(item)
    (item.price - item.rebate) * @vat
  end
end

would report:

Warehouse#total_price refers to item more than self (FeatureEnvy)

since this:

(item.price - item.rebate)

belongs to the Item class, not the Warehouse.

A method with Too Many Statements is any method that has a large number of lines.

Too Many Statements warns about any method that has more than 5 statements. Reek's smell detector for Too Many Statements counts +1 for every simple statement in a method and +1 for every statement within a control structure (if, else, case, when, for, while, until, begin, rescue) but it doesn't count the control structure itself.

So the following method would score +6 in Reek's statement-counting algorithm:

def parse(arg, argv, &error)
  if !(val = arg) and (argv.empty? or /\A-/ =~ (val = argv[0]))
    return nil, block, nil                                         # +1
  end
  opt = (val = parse_arg(val, &error))[1]                          # +2
  val = conv_arg(*val)                                             # +3
  if opt and !arg
    argv.shift                                                     # +4
  else
    val[0] = nil                                                   # +5
  end
  val                                                              # +6
end

(You might argue that the two assigments within the first @if@ should count as statements, and that perhaps the nested assignment should count as +2.)

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

• Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
• Code is considered more complex for each "break in the linear flow of the code"
• Code is considered more complex when "flow breaking structures are nested"

Further reading

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

Reek reports a Manual Dispatch smell if it finds source code that manually checks whether an object responds to a method before that method is called. Manual dispatch is a type of Simulated Polymorphism which leads to code that is harder to reason about, debug, and refactor.

Example

class MyManualDispatcher
  attr_reader :foo

  def initialize(foo)
    @foo = foo
  end

  def call
    foo.bar if foo.respond_to?(:bar)
  end
end

Reek would emit the following warning:

test.rb -- 1 warning:
  [9]: MyManualDispatcher manually dispatches method call (ManualDispatch)

Duplication occurs when two fragments of code look nearly identical, or when two fragments of code have nearly identical effects at some conceptual level.

Reek implements a check for Duplicate Method Call.

Example

Here's a very much simplified and contrived example. The following method will report a warning:

def double_thing()
  @other.thing + @other.thing
end

One quick approach to silence Reek would be to refactor the code thus:

def double_thing()
  thing = @other.thing
  thing + thing
end

A slightly different approach would be to replace all calls of double_thing by calls to @other.double_thing:

class Other
  def double_thing()
    thing + thing
  end
end

The approach you take will depend on balancing other factors in your code.

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

• Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
• Code is considered more complex for each "break in the linear flow of the code"
• Code is considered more complex when "flow breaking structures are nested"

Further reading

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

A NilCheck is a type check. Failures of NilCheck violate the "tell, don't ask" principle.

Additionally, type checks often mask bigger problems in your source code like not using OOP and / or polymorphism when you should.

Example

Given

class Klass
  def nil_checker(argument)
    if argument.nil?
      puts "argument isn't nil!"
    end
  end
end

Reek would emit the following warning:

test.rb -- 1 warning:
  [3]:Klass#nil_checker performs a nil-check. (NilCheck)

A NilCheck is a type check. Failures of NilCheck violate the "tell, don't ask" principle.

Additionally, type checks often mask bigger problems in your source code like not using OOP and / or polymorphism when you should.

Example

Given

class Klass
  def nil_checker(argument)
    if argument.nil?
      puts "argument isn't nil!"
    end
  end
end

Reek would emit the following warning:

test.rb -- 1 warning:
  [3]:Klass#nil_checker performs a nil-check. (NilCheck)

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop enforces the use of a single string formatting utility. Valid options include Kernel#format, Kernel#sprintf and String#%.

The detection of String#% cannot be implemented in a reliable manner for all cases, so only two scenarios are considered - if the first argument is a string literal and if the second argument is an array literal.

Example: EnforcedStyle: format(default)

# bad
puts sprintf('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts format('%10s', 'hoge')

Example: EnforcedStyle: sprintf

# bad
puts format('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts sprintf('%10s', 'hoge')

Example: EnforcedStyle: percent

# bad
puts format('%10s', 'hoge')
puts sprintf('%10s', 'hoge')

# good
puts '%10s' % 'hoge'

This cop enforces the use of a single string formatting utility. Valid options include Kernel#format, Kernel#sprintf and String#%.

The detection of String#% cannot be implemented in a reliable manner for all cases, so only two scenarios are considered - if the first argument is a string literal and if the second argument is an array literal.

Example: EnforcedStyle: format(default)

# bad
puts sprintf('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts format('%10s', 'hoge')

Example: EnforcedStyle: sprintf

# bad
puts format('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts sprintf('%10s', 'hoge')

Example: EnforcedStyle: percent

# bad
puts format('%10s', 'hoge')
puts sprintf('%10s', 'hoge')

# good
puts '%10s' % 'hoge'

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

This cop enforces the use of a single string formatting utility. Valid options include Kernel#format, Kernel#sprintf and String#%.

The detection of String#% cannot be implemented in a reliable manner for all cases, so only two scenarios are considered - if the first argument is a string literal and if the second argument is an array literal.

Example: EnforcedStyle: format(default)

# bad
puts sprintf('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts format('%10s', 'hoge')

Example: EnforcedStyle: sprintf

# bad
puts format('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts sprintf('%10s', 'hoge')

Example: EnforcedStyle: percent

# bad
puts format('%10s', 'hoge')
puts sprintf('%10s', 'hoge')

# good
puts '%10s' % 'hoge'

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

This cops checks if empty lines around the bodies of modules match the configuration.

Example: EnforcedStyle: empty_lines

# good

module Foo

  def bar
    # ...
  end

end

Example: EnforcedStyle: emptylinesexcept_namespace

# good

module Foo
  module Bar

    # ...

  end
end

Example: EnforcedStyle: emptylinesspecial

# good
module Foo

  def bar; end

end

Example: EnforcedStyle: noemptylines (default)

# good

module Foo
  def bar
    # ...
  end
end

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop checks the style of children definitions at classes and modules. Basically there are two different styles:

Example: EnforcedStyle: nested (default)

# good
# have each child on its own line
class Foo
  class Bar
  end
end

Example: EnforcedStyle: compact

# good
# combine definitions as much as possible
class Foo::Bar
end

The compact style is only forced for classes/modules with one child.

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop identifies places where URI.escape can be replaced by CGI.escape, URI.encode_www_form or URI.encode_www_form_component depending on your specific use case. Also this cop identifies places where URI.unescape can be replaced by CGI.unescape, URI.decode_www_form or URI.decode_www_form_component depending on your specific use case.

Example:

# bad
URI.escape('http://example.com')
URI.encode('http://example.com')

# good
CGI.escape('http://example.com')
URI.encode_www_form([['example', 'param'], ['lang', 'en']])
URI.encode_www_form(page: 10, locale: 'en')
URI.encode_www_form_component('http://example.com')

# bad
URI.unescape(enc_uri)
URI.decode(enc_uri)

# good
CGI.unescape(enc_uri)
URI.decode_www_form(enc_uri)
URI.decode_www_form_component(enc_uri)

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

This cops checks if empty lines around the bodies of modules match the configuration.

Example: EnforcedStyle: empty_lines

# good

module Foo

  def bar
    # ...
  end

end

Example: EnforcedStyle: emptylinesexcept_namespace

# good

module Foo
  module Bar

    # ...

  end
end

Example: EnforcedStyle: emptylinesspecial

# good
module Foo

  def bar; end

end

Example: EnforcedStyle: noemptylines (default)

# good

module Foo
  def bar
    # ...
  end
end

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop checks for missing top-level documentation of classes and modules. Classes with no body are exempt from the check and so are namespace modules - modules that have nothing in their bodies except classes, other modules, or constant definitions.

The documentation requirement is annulled if the class or module has a "#:nodoc:" comment next to it. Likewise, "#:nodoc: all" does the same for all its children.

Example:

# bad
class Person
  # ...
end

# good
# Description/Explanation of Person class
class Person
  # ...
end

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

This cop enforces the consistent usage of %-literal delimiters.

Specify the 'default' key to set all preferred delimiters at once. You can continue to specify individual preferred delimiters to override the default.

Example:

# Style/PercentLiteralDelimiters:
#   PreferredDelimiters:
#     default: '[]'
#     '%i':    '()'

# good
%w[alpha beta] + %i(gamma delta)

# bad
%W(alpha #{beta})

# bad
%I(alpha beta)

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop enforces the use of a single string formatting utility. Valid options include Kernel#format, Kernel#sprintf and String#%.

The detection of String#% cannot be implemented in a reliable manner for all cases, so only two scenarios are considered - if the first argument is a string literal and if the second argument is an array literal.

Example: EnforcedStyle: format(default)

# bad
puts sprintf('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts format('%10s', 'hoge')

Example: EnforcedStyle: sprintf

# bad
puts format('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts sprintf('%10s', 'hoge')

Example: EnforcedStyle: percent

# bad
puts format('%10s', 'hoge')
puts sprintf('%10s', 'hoge')

# good
puts '%10s' % 'hoge'

Use a consistent style for named format string tokens.

Note: unannotated style cop only works for strings which are passed as arguments to those methods: sprintf, format, %. The reason is that unannotated format is very similar to encoded URLs or Date/Time formatting strings.

Example: EnforcedStyle: annotated (default)

# bad
format('%{greeting}', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%<greeting>s', greeting: 'Hello')</greeting>

Example: EnforcedStyle: template

# bad
format('%<greeting>s', greeting: 'Hello')
format('%s', 'Hello')

# good
format('%{greeting}', greeting: 'Hello')</greeting>

Example: EnforcedStyle: unannotated

# bad
format('%<greeting>s', greeting: 'Hello')
format('%{greeting}', 'Hello')

# good
format('%s', 'Hello')</greeting>

This cop checks the indentation of the right hand side operand in binary operations that span more than one line.

Example:

# bad
if a +
b
  something
end

# good
if a +
   b
  something
end

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

Checks that brackets used for array literals have or don't have surrounding space depending on configuration.

Example: EnforcedStyle: space

# The `space` style enforces that array literals have
# surrounding space.

# bad
array = [a, b, c, d]

# good
array = [ a, b, c, d ]

Example: EnforcedStyle: no_space

# The `no_space` style enforces that array literals have
# no surrounding space.

# bad
array = [ a, b, c, d ]

# good
array = [a, b, c, d]

Example: EnforcedStyle: compact

# The `compact` style normally requires a space inside
# array brackets, with the exception that successive left
# or right brackets are collapsed together in nested arrays.

# bad
array = [ a, [ b, c ] ]

# good
array = [ a, [ b, c ]]

This cop enforces the use of a single string formatting utility. Valid options include Kernel#format, Kernel#sprintf and String#%.

The detection of String#% cannot be implemented in a reliable manner for all cases, so only two scenarios are considered - if the first argument is a string literal and if the second argument is an array literal.

Example: EnforcedStyle: format(default)

# bad
puts sprintf('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts format('%10s', 'hoge')

Example: EnforcedStyle: sprintf

# bad
puts format('%10s', 'hoge')
puts '%10s' % 'hoge'

# good
puts sprintf('%10s', 'hoge')

Example: EnforcedStyle: percent

# bad
puts format('%10s', 'hoge')
puts sprintf('%10s', 'hoge')

# good
puts '%10s' % 'hoge'