Basquiat::Adapters::RabbitMq#listen has boolean parameter 'block' Open
def listen(block: true, rescue_proc: Basquiat.configuration.rescue_proc)
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Boolean Parameter
is a special case of Control Couple
, where a method parameter is defaulted to true or false. A Boolean Parameter effectively permits a method's caller to decide which execution path to take. This is a case of bad cohesion. You're creating a dependency between methods that is not really necessary, thus increasing coupling.
Example
Given
class Dummy
def hit_the_switch(switch = true)
if switch
puts 'Hitting the switch'
# do other things...
else
puts 'Not hitting the switch'
# do other things...
end
end
end
Reek would emit the following warning:
test.rb -- 3 warnings:
[1]:Dummy#hit_the_switch has boolean parameter 'switch' (BooleanParameter)
[2]:Dummy#hit_the_switch is controlled by argument switch (ControlParameter)
Note that both smells are reported, Boolean Parameter
and Control Parameter
.
Getting rid of the smell
This is highly dependent on your exact architecture, but looking at the example above what you could do is:
- Move everything in the
if
branch into a separate method - Move everything in the
else
branch into a separate method - Get rid of the
hit_the_switch
method alltogether - Make the decision what method to call in the initial caller of
hit_the_switch
Basquiat::Adapters::RabbitMq assumes too much for instance variable '@configuration' Open
class RabbitMq < Basquiat::Adapters::Base
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Basquiat::Adapters::RabbitMq#session_pool calls 'options[:publisher][:session_pool]' 2 times Open
@session_pool ||= ConnectionPool.new(size: options[:publisher][:session_pool].fetch(:size, 1),
timeout: options[:publisher][:session_pool].fetch(:timeout, 5)) do
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Basquiat::Adapters::RabbitMq#publish calls 'options[:publisher]' 2 times Open
if options[:publisher][:session_pool]
session_pool.with { |session| session.publish(event, message, props) }
else
session.publish(event, message, props)
end
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Basquiat::Adapters::RabbitMq#session_pool calls 'options[:publisher]' 2 times Open
@session_pool ||= ConnectionPool.new(size: options[:publisher][:session_pool].fetch(:size, 1),
timeout: options[:publisher][:session_pool].fetch(:timeout, 5)) do
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Use each_key
instead of keys.each
. Open
procs.keys.each { |key| session.bind_queue(key) }
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
This cop checks for uses of each_key
and each_value
Hash methods.
Note: If you have an array of two-element arrays, you can put parentheses around the block arguments to indicate that you're not working with a hash, and suppress RuboCop offenses.
Example:
# bad
hash.keys.each { |k| p k }
hash.values.each { |v| p v }
hash.each { |k, _v| p k }
hash.each { |_k, v| p v }
# good
hash.each_key { |k| p k }
hash.each_value { |v| p v }