ifmeorg/ifme

Checks for if and unless statements that would fit on one line if written as modifier if/unless. The cop also checks for modifier if/unless lines that exceed the maximum line length.

The maximum line length is configured in the Layout/LineLength cop. The tab size is configured in the IndentationWidth of the Layout/IndentationStyle cop.

One-line pattern matching is always allowed. To ensure that there are few cases where the match variable is not used, and to prevent oversights. The variable x becomes undefined and raises NameError when the following example is changed to the modifier form:

if [42] in [x]
  x # `x` is undefined when using modifier form.
end

NOTE: It is allowed when defined? argument has an undefined value, because using the modifier form causes the following incompatibility:

unless defined?(undefined_foo)
  undefined_foo = 'default_value'
end
undefined_foo # => 'default_value'
 
undefined_bar = 'default_value' unless defined?(undefined_bar)
undefined_bar # => nil

Example:

# bad
if condition
  do_stuff(bar)
end
 
unless qux.empty?
  Foo.do_something
end
 
do_something_with_a_long_name(arg) if long_condition_that_prevents_code_fit_on_single_line
 
# good
do_stuff(bar) if condition
Foo.do_something unless qux.empty?
 
if long_condition_that_prevents_code_fit_on_single_line
  do_something_with_a_long_name(arg)
end
 
if short_condition # a long comment that makes it too long if it were just a single line
  do_something
end

Checks for places where string concatenation can be replaced with string interpolation.

The cop can autocorrect simple cases but will skip autocorrecting more complex cases where the resulting code would be harder to read. In those cases, it might be useful to extract statements to local variables or methods which you can then interpolate in a string.

NOTE: When concatenation between two strings is broken over multiple lines, this cop does not register an offense; instead, Style/LineEndConcatenation will pick up the offense if enabled.

Two modes are supported: 1. aggressive style checks and corrects all occurrences of + where either the left or right side of + is a string literal. 2. conservative style on the other hand, checks and corrects only if left side (receiver of + method call) is a string literal. This is useful when the receiver is some expression that returns string like Pathname instead of a string literal.

Safety:

This cop is unsafe in aggressive mode, as it cannot be guaranteed that the receiver is actually a string, which can result in a false positive.

Example: Mode: aggressive (default)

# bad
email_with_name = user.name + ' <' + user.email + '>'
Pathname.new('/') + 'test'
 
# good
email_with_name = "#{user.name} <#{user.email}>"
email_with_name = format('%s <%s>', user.name, user.email)
"#{Pathname.new('/')}test"
 
# accepted, line-end concatenation
name = 'First' +
  'Last'

Example: Mode: conservative

# bad
'Hello' + user.name
 
# good
"Hello #{user.name}"
user.name + '!!'
Pathname.new('/') + 'test'

This cop is used to identify usages of all.each and change them to use all.find_each instead.

Example:

# bad
User.all.each
 
# good
User.all.find_each

Checks for useless method definitions, specifically: empty constructors and methods just delegating to super.

Safety:

This cop is unsafe as it can register false positives for cases when an empty constructor just overrides the parent constructor, which is bad anyway.

Example:

# bad
def initialize
  super
end
 
def method
  super
end
 
# good - with default arguments
def initialize(x = Object.new)
  super
end
 
# good
def initialize
  super
  initialize_internals
end
 
def method(*args)
  super(:extra_arg, *args)
end

Checks for places where string concatenation can be replaced with string interpolation.

The cop can autocorrect simple cases but will skip autocorrecting more complex cases where the resulting code would be harder to read. In those cases, it might be useful to extract statements to local variables or methods which you can then interpolate in a string.

NOTE: When concatenation between two strings is broken over multiple lines, this cop does not register an offense; instead, Style/LineEndConcatenation will pick up the offense if enabled.

Two modes are supported: 1. aggressive style checks and corrects all occurrences of + where either the left or right side of + is a string literal. 2. conservative style on the other hand, checks and corrects only if left side (receiver of + method call) is a string literal. This is useful when the receiver is some expression that returns string like Pathname instead of a string literal.

Safety:

This cop is unsafe in aggressive mode, as it cannot be guaranteed that the receiver is actually a string, which can result in a false positive.

Example: Mode: aggressive (default)

# bad
email_with_name = user.name + ' <' + user.email + '>'
Pathname.new('/') + 'test'
 
# good
email_with_name = "#{user.name} <#{user.email}>"
email_with_name = format('%s <%s>', user.name, user.email)
"#{Pathname.new('/')}test"
 
# accepted, line-end concatenation
name = 'First' +
  'Last'

Example: Mode: conservative

# bad
'Hello' + user.name
 
# good
"Hello #{user.name}"
user.name + '!!'
Pathname.new('/') + 'test'

This cop is used to identify usages of all.each and change them to use all.find_each instead.

Example:

# bad
User.all.each
 
# good
User.all.find_each

For more information visit Source: http://eslint.org/docs/rules/

Checks for places where string concatenation can be replaced with string interpolation.

The cop can autocorrect simple cases but will skip autocorrecting more complex cases where the resulting code would be harder to read. In those cases, it might be useful to extract statements to local variables or methods which you can then interpolate in a string.

NOTE: When concatenation between two strings is broken over multiple lines, this cop does not register an offense; instead, Style/LineEndConcatenation will pick up the offense if enabled.

Two modes are supported: 1. aggressive style checks and corrects all occurrences of + where either the left or right side of + is a string literal. 2. conservative style on the other hand, checks and corrects only if left side (receiver of + method call) is a string literal. This is useful when the receiver is some expression that returns string like Pathname instead of a string literal.

Safety:

This cop is unsafe in aggressive mode, as it cannot be guaranteed that the receiver is actually a string, which can result in a false positive.

Example: Mode: aggressive (default)

# bad
email_with_name = user.name + ' <' + user.email + '>'
Pathname.new('/') + 'test'
 
# good
email_with_name = "#{user.name} <#{user.email}>"
email_with_name = format('%s <%s>', user.name, user.email)
"#{Pathname.new('/')}test"
 
# accepted, line-end concatenation
name = 'First' +
  'Last'

Example: Mode: conservative

# bad
'Hello' + user.name
 
# good
"Hello #{user.name}"
user.name + '!!'
Pathname.new('/') + 'test'

Checks for places where keyword arguments can be used instead of boolean arguments when defining methods. respond_to_missing? method is allowed by default. These are customizable with AllowedMethods option.

Safety:

This cop is unsafe because changing a method signature will implicitly change behavior.

Example:

# bad
def some_method(bar = false)
  puts bar
end
 
# bad - common hack before keyword args were introduced
def some_method(options = {})
  bar = options.fetch(:bar, false)
  puts bar
end
 
# good
def some_method(bar: false)
  puts bar
end

Example: AllowedMethods: ['some_method']

# good
def some_method(bar = false)
  puts bar
end

Use symbols as procs when possible.

If you prefer a style that allows block for method with arguments, please set true to AllowMethodsWithArguments. define_method? methods are allowed by default. These are customizable with AllowedMethods option.

Safety:

This cop is unsafe because there is a difference that a Proc generated from Symbol#to_proc behaves as a lambda, while a Proc generated from a block does not. For example, a lambda will raise an ArgumentError if the number of arguments is wrong, but a non-lambda Proc will not.

For example:

class Foo
  def bar
    :bar
  end
end
 
def call(options = {}, &block)
  block.call(Foo.new, options)
end
 
call { |x| x.bar }
#=> :bar
call(&:bar)
# ArgumentError: wrong number of arguments (given 1, expected 0)

Example:

# bad
something.map { |s| s.upcase }
something.map { _1.upcase }
 
# good
something.map(&:upcase)

Example: AllowMethodsWithArguments: false (default)

# bad
something.do_something(foo) { |o| o.bar }
 
# good
something.do_something(foo, &:bar)

Example: AllowMethodsWithArguments: true

# good
something.do_something(foo) { |o| o.bar }

Example: AllowComments: false (default)

# bad
something.do_something do |s| # some comment
  # some comment
  s.upcase # some comment
  # some comment
end

Example: AllowComments: true

# good  - if there are comment in either position
something.do_something do |s| # some comment
  # some comment
  s.upcase # some comment
  # some comment
end

Example: AllowedMethods: [define_method] (default)

# good
define_method(:foo) { |foo| foo.bar }

Example: AllowedPatterns: [] (default)

# bad
something.map { |s| s.upcase }

Example: AllowedPatterns: ['map'] (default)

# good
something.map { |s| s.upcase }

Checks that there are no repeated bodies within if/unless, case-when, case-in and rescue constructs.

With IgnoreLiteralBranches: true, branches are not registered as offenses if they return a basic literal value (string, symbol, integer, float, rational, complex, true, false, or nil), or return an array, hash, regexp or range that only contains one of the above basic literal values.

With IgnoreConstantBranches: true, branches are not registered as offenses if they return a constant value.

Example:

# bad
if foo
  do_foo
  do_something_else
elsif bar
  do_foo
  do_something_else
end
 
# good
if foo || bar
  do_foo
  do_something_else
end
 
# bad
case x
when foo
  do_foo
when bar
  do_foo
else
  do_something_else
end
 
# good
case x
when foo, bar
  do_foo
else
  do_something_else
end
 
# bad
begin
  do_something
rescue FooError
  handle_error
rescue BarError
  handle_error
end
 
# good
begin
  do_something
rescue FooError, BarError
  handle_error
end

Example: IgnoreLiteralBranches: true

# good
case size
when "small" then 100
when "medium" then 250
when "large" then 1000
else 250
end

Example: IgnoreConstantBranches: true

# good
case size
when "small" then SMALL_SIZE
when "medium" then MEDIUM_SIZE
when "large" then LARGE_SIZE
else MEDIUM_SIZE
end

This cop is used to identify usages of all.each and change them to use all.find_each instead.

Example:

# bad
User.all.each
 
# good
User.all.find_each

Checks for places where string concatenation can be replaced with string interpolation.

The cop can autocorrect simple cases but will skip autocorrecting more complex cases where the resulting code would be harder to read. In those cases, it might be useful to extract statements to local variables or methods which you can then interpolate in a string.

NOTE: When concatenation between two strings is broken over multiple lines, this cop does not register an offense; instead, Style/LineEndConcatenation will pick up the offense if enabled.

Two modes are supported: 1. aggressive style checks and corrects all occurrences of + where either the left or right side of + is a string literal. 2. conservative style on the other hand, checks and corrects only if left side (receiver of + method call) is a string literal. This is useful when the receiver is some expression that returns string like Pathname instead of a string literal.

Safety:

This cop is unsafe in aggressive mode, as it cannot be guaranteed that the receiver is actually a string, which can result in a false positive.

Example: Mode: aggressive (default)

# bad
email_with_name = user.name + ' <' + user.email + '>'
Pathname.new('/') + 'test'
 
# good
email_with_name = "#{user.name} <#{user.email}>"
email_with_name = format('%s <%s>', user.name, user.email)
"#{Pathname.new('/')}test"
 
# accepted, line-end concatenation
name = 'First' +
  'Last'

Example: Mode: conservative

# bad
'Hello' + user.name
 
# good
"Hello #{user.name}"
user.name + '!!'
Pathname.new('/') + 'test'

Identifies places where if-elsif constructions can be replaced with case-when.

Safety:

This cop is unsafe. case statements use === for equality, so if the original conditional used a different equality operator, the behavior may be different.

Example: MinBranchesCount: 3 (default)

# bad
if status == :active
  perform_action
elsif status == :inactive || status == :hibernating
  check_timeout
elsif status == :invalid
  report_invalid
else
  final_action
end
 
# good
case status
when :active
  perform_action
when :inactive, :hibernating
  check_timeout
when :invalid
  report_invalid
else
  final_action
end

Example: MinBranchesCount: 4

# good
if status == :active
  perform_action
elsif status == :inactive || status == :hibernating
  check_timeout
elsif status == :invalid
  report_invalid
else
  final_action
end

Checks hash literal syntax.

It can enforce either the use of the class hash rocket syntax or the use of the newer Ruby 1.9 syntax (when applicable).

A separate offense is registered for each problematic pair.

The supported styles are:

• ruby19 - forces use of the 1.9 syntax (e.g. {a: 1}) when hashes have all symbols for keys
• hash_rockets - forces use of hash rockets for all hashes
• nomixedkeys - simply checks for hashes with mixed syntaxes
• ruby19nomixed_keys - forces use of ruby 1.9 syntax and forbids mixed syntax hashes

This cop has EnforcedShorthandSyntax option. It can enforce either the use of the explicit hash value syntax or the use of Ruby 3.1's hash value shorthand syntax.

The supported styles are:

• always - forces use of the 3.1 syntax (e.g. {foo:})
• never - forces use of explicit hash literal value
• either - accepts both shorthand and explicit use of hash literal value
• consistent - forces use of the 3.1 syntax only if all values can be omitted in the hash

Example: EnforcedStyle: ruby19 (default)

# bad
{:a => 2}
{b: 1, :c => 2}
 
# good
{a: 2, b: 1}
{:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
{d: 1, 'e' => 2} # technically not forbidden

Example: EnforcedStyle: hash_rockets

# bad
{a: 1, b: 2}
{c: 1, 'd' => 5}
 
# good
{:a => 1, :b => 2}

Example: EnforcedStyle: nomixedkeys

# bad
{:a => 1, b: 2}
{c: 1, 'd' => 2}
 
# good
{:a => 1, :b => 2}
{c: 1, d: 2}

Example: EnforcedStyle: ruby19nomixed_keys

# bad
{:a => 1, :b => 2}
{c: 2, 'd' => 3} # should just use hash rockets
 
# good
{a: 1, b: 2}
{:c => 3, 'd' => 4}

Example: EnforcedShorthandSyntax: always (default)

# bad
{foo: foo, bar: bar}
 
# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: never

# bad
{foo:, bar:}
 
# good
{foo: foo, bar: bar}

Example: EnforcedShorthandSyntax: either

# good
{foo: foo, bar: bar}
 
# good
{foo: foo, bar:}
 
# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: consistent

# bad - `foo` and `bar` values can be omitted
{foo: foo, bar: bar}
 
# bad - `bar` value can be omitted
{foo:, bar: bar}
 
# bad - mixed syntaxes
{foo:, bar: baz}
 
# good
{foo:, bar:}
 
# good - can't omit `baz`
{foo: foo, bar: baz}