Showing 5,267 of 5,604 total issues
PaymentGateways::StripeCrypt#update_billing_address refers to 'billing_address' more than self (maybe move it to another class?) Open
line1: billing_address[:address1],
line2: billing_address[:address2],
city: billing_address[:city],
state: billing_address[:state],
postal_code: billing_address[:zip],- 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
endwould 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.
Pdf::Finance::InvoiceReportData#person_data refers to 'pd' more than self (maybe move it to another class?) Open
pd << ['Fiscal code', fiscal_code] if fiscal_code.present?
pd << [@invoice.buyer_account.field_label('vat_code'), vat_code] if vat_code.present?
pd << ['PO num', po_number] if po_number.present?- 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
endwould 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.
Pdf::Report has at least 28 methods Open
class Report- Read upRead up
- Exclude checks
Too Many Methods is a special case of LargeClass.
Example
Given this configuration
TooManyMethods:
max_methods: 3and this code:
class TooManyMethods
def one; end
def two; end
def three; end
def four; end
endReek would emit the following warning:
test.rb -- 1 warning:
[1]:TooManyMethods has at least 4 methods (TooManyMethods)RedhatCustomerPortalSupport#redhat_account_recently_verified? refers to 'extra_fields_change' more than self (maybe move it to another class?) Open
verified_by_was = extra_fields_change.first[:red_hat_account_verified_by]
verified_by = extra_fields_change.last[:red_hat_account_verified_by]- 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
endwould 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.
Pdf::Finance::InvoiceGenerator#print_header has approx 9 statements Open
def print_header- 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.)
SimpleLayout#create_builtin_partial! refers to 'p' more than self (maybe move it to another class?) Open
p.system_name = system_name
p.draft = CMS::Builtin::Partial.filesystem_templates.fetch(system_name).read
p.liquid_enabled = true- 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
endwould 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.
Stats::Base#extract_since refers to 'options' more than self (maybe move it to another class?) Open
timezone = options[:timezone]
since = options[:since]
period = sanitize_period(options[:period])- 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
endwould 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.
Stats::Base#period_detail refers to 'range' more than self (maybe move it to another class?) Open
timezone = options[:timezone] ? extract_timezone(options) : range.begin.time_zone
{
name: options[:period],
since: range.begin,- 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
endwould 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.
Stats::Storage#timeshift_values_by_deltas has 4 parameters Open
def timeshift_values_by_deltas(shift, values, deltas, granularity)- 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
endReek 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.
Stats::Base#to_time refers to 'stuff' more than self (maybe move it to another class?) Open
return stuff if stuff.acts_like?(:time)
begin
zone.parse(stuff.to_s)- 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
endwould 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.
Stats::Deprecated#self.usage_in_day has approx 12 statements Open
def self.usage_in_day(service, options = {})- 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.)
Stats::Views::ActiveClients#active_clients_progress refers to 'options' more than self (maybe move it to another class?) Open
options = options.symbolize_keys
options.assert_valid_keys(:since, :until, :range, :timezone)
options[:granularity] ||= :day
range = extract_range(options)- 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
endwould 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.
Stats::Storage#ordered_hash has approx 19 statements Open
def ordered_hash(since, period, options)- 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.)
Stats::Views::Csv::TopApplications#generate refers to 'app' more than self (maybe move it to another class?) Open
csv << [app[:name], app[:id], app[:plan][:name], app[:plan][:id], app[:account][:name], app[:account][:id], app[:value]]- 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
endwould 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.
Stats::Views::Total#total has approx 15 statements Open
def total(options)- 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.)
ThreeScale::Analytics::AccountClassifier#initialize is controlled by argument 'account' Open
@account = account || EMPTY_ACCOUNT- Read upRead up
- Exclude checks
Control Parameter is a special case of Control Couple
Example
A simple example would be the "quoted" parameter in the following method:
def write(quoted)
if quoted
write_quoted @value
else
write_unquoted @value
end
endFixing those problems is out of the scope of this document but an easy solution could be to remove the "write" method alltogether and to move the calls to "writequoted" / "writeunquoted" in the initial caller of "write".
ThreeScale::Diff#initialize is controlled by argument 'base' Open
@base = base || ""- Read upRead up
- Exclude checks
Control Parameter is a special case of Control Couple
Example
A simple example would be the "quoted" parameter in the following method:
def write(quoted)
if quoted
write_quoted @value
else
write_unquoted @value
end
endFixing those problems is out of the scope of this document but an easy solution could be to remove the "write" method alltogether and to move the calls to "writequoted" / "writeunquoted" in the initial caller of "write".
ThreeScale::Diff#to_s has approx 12 statements Open
def to_s- 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.)
SimpleLayout#import! has approx 9 statements Open
def import! # _all- 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.)
Stats::Base#extract_since has approx 8 statements Open
def extract_since(options)- 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.)