Assignment Branch Condition size for run is too high. [27.73/15] Open
def run
return false unless super
@credentials = [{
username: 'Username', password: 'Password Hash', email: 'E-mail'
- Read upRead up
- Exclude checks
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
Cyclomatic complexity for run is too high. [7/6] Open
def run
return false unless super
@credentials = [{
username: 'Username', password: 'Password Hash', email: 'E-mail'
- Read upRead up
- Exclude checks
This cop checks that the cyclomatic complexity of methods is not higher than the configured maximum. The cyclomatic complexity is the number of linearly independent paths through a method. The algorithm counts decision points and adds one.
An if statement (or unless or ?:) increases the complexity by one. An else branch does not, since it doesn't add a decision point. The && operator (or keyword and) can be converted to a nested if statement, and ||/or is shorthand for a sequence of ifs, so they also add one. Loops can be said to have an exit condition, so they add one.
Method initialize
has 27 lines of code (exceeds 25 allowed). Consider refactoring. Open
def initialize
super
update_info(
name: 'Ultimate CSV Importer User Table Extract',
Method run
has 27 lines of code (exceeds 25 allowed). Consider refactoring. Open
def run
return false unless super
@credentials = [{
username: 'Username', password: 'Password Hash', email: 'E-mail'
Method run
has a Cognitive Complexity of 8 (exceeds 5 allowed). Consider refactoring. Open
def run
return false unless super
@credentials = [{
username: 'Username', password: 'Password Hash', email: 'E-mail'
- Read upRead up
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
Avoid rescuing without specifying an error class. Open
rescue
- Read upRead up
- Exclude checks
This cop checks for rescuing StandardError
. There are two supported
styles implicit
and explicit
. This cop will not register an offense
if any error other than StandardError
is specified.
Example: EnforcedStyle: implicit
# `implicit` will enforce using `rescue` instead of
# `rescue StandardError`.
# bad
begin
foo
rescue StandardError
bar
end
# good
begin
foo
rescue
bar
end
# good
begin
foo
rescue OtherError
bar
end
# good
begin
foo
rescue StandardError, SecurityError
bar
end
Example: EnforcedStyle: explicit (default)
# `explicit` will enforce using `rescue StandardError`
# instead of `rescue`.
# bad
begin
foo
rescue
bar
end
# good
begin
foo
rescue StandardError
bar
end
# good
begin
foo
rescue OtherError
bar
end
# good
begin
foo
rescue StandardError, SecurityError
bar
end
Use safe navigation (&.
) instead of checking if an object exists before calling the method. Open
field && field.empty? ? nil : field
- Read upRead up
- Exclude checks
This cop transforms usages of a method call safeguarded by a non nil
check for the variable whose method is being called to
safe navigation (&.
).
Configuration option: ConvertCodeThatCanStartToReturnNil
The default for this is false
. When configured to true
, this will
check for code in the format !foo.nil? && foo.bar
. As it is written,
the return of this code is limited to false
and whatever the return
of the method is. If this is converted to safe navigation,
foo&.bar
can start returning nil
as well as what the method
returns.
Example:
# bad
foo.bar if foo
foo.bar(param1, param2) if foo
foo.bar { |e| e.something } if foo
foo.bar(param) { |e| e.something } if foo
foo.bar if !foo.nil?
foo.bar unless !foo
foo.bar unless foo.nil?
foo && foo.bar
foo && foo.bar(param1, param2)
foo && foo.bar { |e| e.something }
foo && foo.bar(param) { |e| e.something }
# good
foo&.bar
foo&.bar(param1, param2)
foo&.bar { |e| e.something }
foo&.bar(param) { |e| e.something }
foo.nil? || foo.bar
!foo || foo.bar
# Methods that `nil` will `respond_to?` should not be converted to
# use safe navigation
foo.to_i if foo
Use 2 spaces for indentation in a hash, relative to the first position after the preceding left parenthesis. Open
username: row[:user_login],
- Read upRead up
- Exclude checks
This cops checks the indentation of the first key in a hash literal where the opening brace and the first key are on separate lines. The other keys' indentations are handled by the AlignHash cop.
By default, Hash literals that are arguments in a method call with parentheses, and where the opening curly brace of the hash is on the same line as the opening parenthesis of the method call, shall have their first key indented one step (two spaces) more than the position inside the opening parenthesis.
Other hash literals shall have their first key indented one step more than the start of the line where the opening curly brace is.
This default style is called 'specialinsideparentheses'. Alternative styles are 'consistent' and 'align_braces'. Here are examples:
Example: EnforcedStyle: specialinsideparentheses (default)
# The `special_inside_parentheses` style enforces that the first key
# in a hash literal where the opening brace and the first key are on
# separate lines is indented one step (two spaces) more than the
# position inside the opening parentheses.
# bad
hash = {
key: :value
}
and_in_a_method_call({
no: :difference
})
# good
special_inside_parentheses
hash = {
key: :value
}
but_in_a_method_call({
its_like: :this
})
Example: EnforcedStyle: consistent
# The `consistent` style enforces that the first key in a hash
# literal where the opening brace and the first key are on
# seprate lines is indented the same as a hash literal which is not
# defined inside a method call.
# bad
hash = {
key: :value
}
but_in_a_method_call({
its_like: :this
})
# good
hash = {
key: :value
}
and_in_a_method_call({
no: :difference
})
Example: EnforcedStyle: align_braces
# The `align_brackets` style enforces that the opening and closing
# braces are indented to the same position.
# bad
and_now_for_something = {
completely: :different
}
# good
and_now_for_something = {
completely: :different
}
Indent the right brace the same as the first position after the preceding left parenthesis. Open
})
- Read upRead up
- Exclude checks
This cops checks the indentation of the first key in a hash literal where the opening brace and the first key are on separate lines. The other keys' indentations are handled by the AlignHash cop.
By default, Hash literals that are arguments in a method call with parentheses, and where the opening curly brace of the hash is on the same line as the opening parenthesis of the method call, shall have their first key indented one step (two spaces) more than the position inside the opening parenthesis.
Other hash literals shall have their first key indented one step more than the start of the line where the opening curly brace is.
This default style is called 'specialinsideparentheses'. Alternative styles are 'consistent' and 'align_braces'. Here are examples:
Example: EnforcedStyle: specialinsideparentheses (default)
# The `special_inside_parentheses` style enforces that the first key
# in a hash literal where the opening brace and the first key are on
# separate lines is indented one step (two spaces) more than the
# position inside the opening parentheses.
# bad
hash = {
key: :value
}
and_in_a_method_call({
no: :difference
})
# good
special_inside_parentheses
hash = {
key: :value
}
but_in_a_method_call({
its_like: :this
})
Example: EnforcedStyle: consistent
# The `consistent` style enforces that the first key in a hash
# literal where the opening brace and the first key are on
# seprate lines is indented the same as a hash literal which is not
# defined inside a method call.
# bad
hash = {
key: :value
}
but_in_a_method_call({
its_like: :this
})
# good
hash = {
key: :value
}
and_in_a_method_call({
no: :difference
})
Example: EnforcedStyle: align_braces
# The `align_brackets` style enforces that the opening and closing
# braces are indented to the same position.
# bad
and_now_for_something = {
completely: :different
}
# good
and_now_for_something = {
completely: :different
}
Redundant curly braces around a hash parameter. Open
@credentials.push({
username: row[:user_login],
password: row[:user_pass],
email: row[:user_email]
})
- Read upRead up
- Exclude checks
This cop checks for braces around the last parameter in a method call
if the last parameter is a hash.
It supports braces
, no_braces
and context_dependent
styles.
Example: EnforcedStyle: braces
# The `braces` style enforces braces around all method
# parameters that are hashes.
# bad
some_method(x, y, a: 1, b: 2)
# good
some_method(x, y, {a: 1, b: 2})
Example: EnforcedStyle: no_braces (default)
# The `no_braces` style checks that the last parameter doesn't
# have braces around it.
# bad
some_method(x, y, {a: 1, b: 2})
# good
some_method(x, y, a: 1, b: 2)
Example: EnforcedStyle: context_dependent
# The `context_dependent` style checks that the last parameter
# doesn't have braces around it, but requires braces if the
# second to last parameter is also a hash literal.
# bad
some_method(x, y, {a: 1, b: 2})
some_method(x, y, {a: 1, b: 2}, a: 1, b: 2)
# good
some_method(x, y, a: 1, b: 2)
some_method(x, y, {a: 1, b: 2}, {a: 1, b: 2})
Use a guard clause instead of wrapping the code inside a conditional expression. Open
if row[:user_login] && row[:user_pass]
- Read upRead up
- Exclude checks
Use a guard clause instead of wrapping the code inside a conditional expression
Example:
# bad
def test
if something
work
end
end
# good
def test
return unless something
work
end
# also good
def test
work if something
end
# bad
if something
raise 'exception'
else
ok
end
# good
raise 'exception' if something
ok
Use the new Ruby 1.9 hash syntax. Open
:headers => true,
- Read upRead up
- Exclude checks
This cop 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
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}
Use %i
or %I
for an array of symbols. Open
:converters => [:all, :blank_to_nil]
- Read upRead up
- Exclude checks
This cop can check for array literals made up of symbols that are not using the %i() syntax.
Alternatively, it checks for symbol arrays using the %i() syntax on projects which do not want to use that syntax.
Configuration option: MinSize
If set, arrays with fewer elements than this value will not trigger the
cop. For example, a MinSize of
3` will not enforce a style on an array
of 2 or fewer elements.
Example: EnforcedStyle: percent (default)
# good
%i[foo bar baz]
# bad
[:foo, :bar, :baz]
Example: EnforcedStyle: brackets
# good
[:foo, :bar, :baz]
# bad
%i[foo bar baz]
Use the new Ruby 1.9 hash syntax. Open
:header_converters => :symbol,
- Read upRead up
- Exclude checks
This cop 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
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}
Use the new Ruby 1.9 hash syntax. Open
:col_sep => delimiter,
- Read upRead up
- Exclude checks
This cop 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
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}
Use the new Ruby 1.9 hash syntax. Open
:converters => [:all, :blank_to_nil]
- Read upRead up
- Exclude checks
This cop 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
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}