SVGPath::Absolute#self.circular_arc has 7 parameters Open
def self.circular_arc(r:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:, opts: {})
- Read upRead up
- Exclude checks
A Long Parameter List
occurs when a method has a lot of parameters.
Example
Given
class Dummy
def long_list(foo,bar,baz,fling,flung)
puts foo,bar,baz,fling,flung
end
end
Reek would report the following warning:
test.rb -- 1 warning:
[2]:Dummy#long_list has 5 parameters (LongParameterList)
A common solution to this problem would be the introduction of parameter objects.
SVGPath::Absolute#self.elliptical_arc has 7 parameters Open
def self.elliptical_arc(rx:, ry:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:)
- Read upRead up
- Exclude checks
A Long Parameter List
occurs when a method has a lot of parameters.
Example
Given
class Dummy
def long_list(foo,bar,baz,fling,flung)
puts foo,bar,baz,fling,flung
end
end
Reek would report the following warning:
test.rb -- 1 warning:
[2]:Dummy#long_list has 5 parameters (LongParameterList)
A common solution to this problem would be the introduction of parameter objects.
SVGPath::Absolute has no descriptive comment Open
module Absolute
- 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
SVGPath::Absolute#self.circular_arc has unused parameter 'opts' Open
def self.circular_arc(r:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:, opts: {})
- 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)
SVGPath::Absolute#self.elliptical_arc has the parameter name 'y' Open
def self.elliptical_arc(rx:, ry:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:)
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.circular_arc has the parameter name 'x' Open
def self.circular_arc(r:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:, opts: {})
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.circular_arc has the parameter name 'y' Open
def self.circular_arc(r:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:, opts: {})
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.move_to has the parameter name 'y' Open
def self.move_to(x:, y:)
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.move_to has the parameter name 'x' Open
def self.move_to(x:, y:)
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.elliptical_arc has the parameter name 'x' Open
def self.elliptical_arc(rx:, ry:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:)
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.
SVGPath::Absolute#self.circular_arc has the parameter name 'r' Open
def self.circular_arc(r:, x_axis_rotation: 0, large_arc_flag: 0, sweep_flag: 0, x:, y:, opts: {})
- Read upRead up
- Exclude checks
An Uncommunicative Parameter Name
is a parameter name that doesn't communicate its intent well enough.
Poor names make it hard for the reader to build a mental picture of what's going on in the code. They can also be mis-interpreted; and they hurt the flow of reading, because the reader must slow down to interpret the names.