Class AbstractRecurringTodosBuilder
has 21 methods (exceeds 20 allowed). Consider refactoring. Open
class AbstractRecurringTodosBuilder
attr_reader :mapped_attributes, :pattern
def initialize(user, attributes, pattern_class)
@user = user
RecurringTodos::AbstractRecurringTodosBuilder has at least 21 methods Open
class AbstractRecurringTodosBuilder
- Read upRead up
- Exclude checks
Too Many Methods
is a special case of LargeClass
.
Example
Given this configuration
TooManyMethods:
max_methods: 3
and this code:
class TooManyMethods
def one; end
def two; end
def three; end
def four; end
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:TooManyMethods has at least 4 methods (TooManyMethods)
RecurringTodos::AbstractRecurringTodosBuilder#get_selector has approx 6 statements Open
def get_selector(key)
- Read upRead up
- Exclude checks
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.)
RecurringTodos::AbstractRecurringTodosBuilder#filter_generic_attributes refers to 'attributes' more than self (maybe move it to another class?) Open
recurring_period: attributes[:recurring_period],
description: attributes[:description],
notes: attributes[:notes],
tag_list: tag_list_or_empty_string(attributes),
start_from: attributes[:start_from],
- Read upRead up
- Exclude checks
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.
RecurringTodos::AbstractRecurringTodosBuilder has at least 8 instance variables Open
class AbstractRecurringTodosBuilder
- Read upRead up
- Exclude checks
Too Many Instance Variables
is a special case of LargeClass
.
Example
Given this configuration
TooManyInstanceVariables:
max_instance_variables: 3
and this code:
class TooManyInstanceVariables
def initialize
@arg_1 = :dummy
@arg_2 = :dummy
@arg_3 = :dummy
@arg_4 = :dummy
end
end
Reek would emit the following warning:
test.rb -- 5 warnings:
[1]:TooManyInstanceVariables has at least 4 instance variables (TooManyInstanceVariables)
RecurringTodos::AbstractRecurringTodosBuilder has no descriptive comment Open
class AbstractRecurringTodosBuilder
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
RecurringTodos::AbstractRecurringTodosBuilder#save_tags calls '@filtered_attributes[:tag_list]' 2 times Open
@recurring_todo.tag_with(@filtered_attributes[:tag_list]) if @filtered_attributes[:tag_list].present?
- Read upRead up
- Exclude checks
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.
RecurringTodos::AbstractRecurringTodosBuilder#tag_list_or_empty_string calls 'attributes[:tag_list]' 2 times Open
attributes[:tag_list].blank? ? "" : attributes[:tag_list].strip
- Read upRead up
- Exclude checks
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.
RecurringTodos::AbstractRecurringTodosBuilder assumes too much for instance variable '@recurring_todo' Open
class AbstractRecurringTodosBuilder
- Read upRead up
- Exclude checks
Classes should not assume that instance variables are set or present outside of the current class definition.
Good:
class Foo
def initialize
@bar = :foo
end
def foo?
@bar == :foo
end
end
Good as well:
class Foo
def foo?
bar == :foo
end
def bar
@bar ||= :foo
end
end
Bad:
class Foo
def go_foo!
@bar = :foo
end
def foo?
@bar == :foo
end
end
Example
Running Reek on:
class Dummy
def test
@ivar
end
end
would report:
[1]:InstanceVariableAssumption: Dummy assumes too much for instance variable @ivar
Note that this example would trigger this smell warning as well:
class Parent
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
@omg
end
end
The way to address the smell warning is that you should create an attr_reader
to use @omg
in the subclass and not access @omg
directly like this:
class Parent
attr_reader :omg
def initialize(omg)
@omg = omg
end
end
class Child < Parent
def foo
omg
end
end
Directly accessing instance variables is considered a smell because it breaks encapsulation and makes it harder to reason about code.
If you don't want to expose those methods as public API just make them private like this:
class Parent
def initialize(omg)
@omg = omg
end
private
attr_reader :omg
end
class Child < Parent
def foo
omg
end
end
Current Support in Reek
An instance variable must:
- be set in the constructor
- or be accessed through a method with lazy initialization / memoization.
If not, Instance Variable Assumption will be reported.
RecurringTodos::AbstractRecurringTodosBuilder#map doesn't depend on instance state (maybe move it to another class?) Open
def map(mapping, key, source_key)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
RecurringTodos::AbstractRecurringTodosBuilder#get_selector performs a nil-check Open
return nil if key.nil?
- Read upRead up
- Exclude checks
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)
RecurringTodos::AbstractRecurringTodosBuilder#tag_list_or_empty_string doesn't depend on instance state (maybe move it to another class?) Open
def tag_list_or_empty_string(attributes)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
RecurringTodos::AbstractRecurringTodosBuilder#valid_selector? has unused parameter 'selector' Open
def valid_selector?(selector)
- Read upRead up
- Exclude checks
Unused Parameter
refers to methods with parameters that are unused in scope of the method.
Having unused parameters in a method is code smell because leaving dead code in a method can never improve the method and it makes the code confusing to read.
Example
Given:
class Klass
def unused_parameters(x,y,z)
puts x,y # but not z
end
end
Reek would emit the following warning:
[2]:Klass#unused_parameters has unused parameter 'z' (UnusedParameters)
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
}
Unused method argument - selector
. If it's necessary, use _
or _selector
as an argument name to indicate that it won't be used. You can also write as valid_selector?(*)
if you want the method to accept any arguments but don't care about them. Open
def valid_selector?(selector)
- Read upRead up
- Exclude checks
This cop checks for unused method arguments.
Example:
# bad
def some_method(used, unused, _unused_but_allowed)
puts used
end
Example:
# good
def some_method(used, _unused, _unused_but_allowed)
puts used
end
Redundant return
detected. Open
return selector
- Read upRead up
- Exclude checks
This cop checks for redundant return
expressions.
Example:
def test
return something
end
def test
one
two
three
return something
end
It should be extended to handle methods whose body is if/else or a case expression with a default branch.
Line is too long. [121/120] Open
raise Exception.new, "recurrence selector pattern (#{key}) not given" unless @attributes.selector_key_present?(key)
- Exclude checks
Redundant return
detected. Open
return @saved
- Read upRead up
- Exclude checks
This cop checks for redundant return
expressions.
Example:
def test
return something
end
def test
one
two
three
return something
end
It should be extended to handle methods whose body is if/else or a case expression with a default branch.
Line is too long. [164/120] Open
raise(Exception.new, @recurring_todo.valid? ? "Recurring todo was not saved yet" : "Recurring todos was not saved because of validation errors") unless @saved
- Exclude checks
Missing magic comment # frozen_string_literal: true
. Open
module RecurringTodos
- Read upRead up
- Exclude checks
This cop is designed to help upgrade to Ruby 3.0. It will add the
comment # frozen_string_literal: true
to the top of files to
enable frozen string literals. Frozen string literals may be default
in Ruby 3.0. The comment will be added below a shebang and encoding
comment. The frozen string literal comment is only valid in Ruby 2.3+.
Example: EnforcedStyle: when_needed (default)
# The `when_needed` style will add the frozen string literal comment
# to files only when the `TargetRubyVersion` is set to 2.3+.
# bad
module Foo
# ...
end
# good
# frozen_string_literal: true
module Foo
# ...
end
Example: EnforcedStyle: always
# The `always` style will always add the frozen string literal comment
# to a file, regardless of the Ruby version or if `freeze` or `<<` are
# called on a string literal.
# bad
module Bar
# ...
end
# good
# frozen_string_literal: true
module Bar
# ...
end
Example: EnforcedStyle: never
# The `never` will enforce that the frozen string literal comment does
# not exist in a file.
# bad
# frozen_string_literal: true
module Baz
# ...
end
# good
module Baz
# ...
end
Use 2 spaces for indentation in a hash, relative to the first position after the preceding left parenthesis. Open
recurring_period: attributes[:recurring_period],
- 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 return
detected. Open
return Tracks::AttributeHandler.new(@user, {
- Read upRead up
- Exclude checks
This cop checks for redundant return
expressions.
Example:
def test
return something
end
def test
one
two
three
return something
end
It should be extended to handle methods whose body is if/else or a case expression with a default branch.
Redundant curly braces around a hash parameter. Open
return Tracks::AttributeHandler.new(@user, {
recurring_period: attributes[:recurring_period],
description: attributes[:description],
notes: attributes[:notes],
tag_list: tag_list_or_empty_string(attributes),
- 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})