Showing 5,267 of 5,597 total issues
Liquid::Drops#documentation doesn't depend on instance state (maybe move it to another class?) Open
def documentation
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Filters::RailsHelpers takes parameters ['html_options', 'title', 'url'] to 6 methods Open
def delete_button(title, url, html_options = {})
button title, url, :delete, RailsHelpers.sanitize_options(html_options)
end
desc """
- Read upRead up
- Exclude checks
In general, a Data Clump
occurs when the same two or three items frequently appear together in classes and parameter lists, or when a group of instance variable names start or end with similar substrings.
The recurrence of the items often means there is duplicate code spread around to handle them. There may be an abstraction missing from the code, making the system harder to understand.
Example
Given
class Dummy
def x(y1,y2); end
def y(y1,y2); end
def z(y1,y2); end
end
Reek would emit the following warning:
test.rb -- 1 warning:
[2, 3, 4]:Dummy takes parameters [y1, y2] to 3 methods (DataClump)
A possible way to fix this problem (quoting from Martin Fowler):
The first step is to replace data clumps with objects and use the objects whenever you see them. An immediate benefit is that you'll shrink some parameter lists. The interesting stuff happens as you begin to look for behavior to move into the new objects.
Liquid::Drops::Invitation#sent_at performs a nil-check Open
@invitation.sent_at.nil? ? @invitation.created_at : @invitation.sent_at
- 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)
Liquid::Filters::RailsHelpers takes parameters ['title', 'url'] to 8 methods Open
def delete_button(title, url, html_options = {})
button title, url, :delete, RailsHelpers.sanitize_options(html_options)
end
desc """
- Read upRead up
- Exclude checks
In general, a Data Clump
occurs when the same two or three items frequently appear together in classes and parameter lists, or when a group of instance variable names start or end with similar substrings.
The recurrence of the items often means there is duplicate code spread around to handle them. There may be an abstraction missing from the code, making the system harder to understand.
Example
Given
class Dummy
def x(y1,y2); end
def y(y1,y2); end
def z(y1,y2); end
end
Reek would emit the following warning:
test.rb -- 1 warning:
[2, 3, 4]:Dummy takes parameters [y1, y2] to 3 methods (DataClump)
A possible way to fix this problem (quoting from Martin Fowler):
The first step is to replace data clumps with objects and use the objects whenever you see them. An immediate benefit is that you'll shrink some parameter lists. The interesting stuff happens as you begin to look for behavior to move into the new objects.
DeveloperPortal::Admin::Account::PlanChangesController has missing safe method 'forget_plan_change!' Open
def forget_plan_change!
- Read upRead up
- Exclude checks
A candidate method for the Missing Safe Method
smell are methods whose names end with an exclamation mark.
An exclamation mark in method names means (the explanation below is taken from here ):
The ! in method names that end with ! means, “This method is dangerous”—or, more precisely, this method is the “dangerous” version of an otherwise equivalent method, with the same name minus the !. “Danger” is relative; the ! doesn’t mean anything at all unless the method name it’s in corresponds to a similar but bang-less method name. So, for example, gsub! is the dangerous version of gsub. exit! is the dangerous version of exit. flatten! is the dangerous version of flatten. And so forth.
Such a method is called Missing Safe Method
if and only if her non-bang version does not exist and this method is reported as a smell.
Example
Given
class C
def foo; end
def foo!; end
def bar!; end
end
Reek would report bar!
as Missing Safe Method
smell but not foo!
.
Reek reports this smell only in a class context, not in a module context in order to allow perfectly legit code like this:
class Parent
def foo; end
end
module Dangerous
def foo!; end
end
class Son < Parent
include Dangerous
end
class Daughter < Parent
end
In this example, Reek would not report the Missing Safe Method
smell for the method foo
of the Dangerous
module.
Liquid::Drops::Deprecated#notify? doesn't depend on instance state (maybe move it to another class?) Open
def notify?
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Filters::FormHelpers#error_class doesn't depend on instance state (maybe move it to another class?) Open
def error_class(errors, class_name = DEFAULT_ERROR_CLASS)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Tags::Email#headers is a writable attribute Open
attr_accessor :headers
- Read upRead up
- Exclude checks
A class that publishes a setter for an instance variable invites client classes to become too intimate with its inner workings, and in particular with its representation of state.
The same holds to a lesser extent for getters, but Reek doesn't flag those.
Example
Given:
class Klass
attr_accessor :dummy
end
Reek would emit the following warning:
reek test.rb
test.rb -- 1 warning:
[2]:Klass declares the writable attribute dummy (Attribute)
Liquid::Docs::Text inherits from core class 'String' Open
class Text < String
- Read upRead up
- Exclude checks
Subclassing core classes in Ruby can lead to unexpected side effects.
Knowing that Ruby has a core library, which is written in C, and a standard library, which is written in Ruby, if you do not know exactly how these core classes operate at the C level, you are gonna have a bad time.
Source: http://words.steveklabnik.com/beware-subclassing-ruby-core-classes
Liquid::Tags::CSRF#render doesn't depend on instance state (maybe move it to another class?) Open
def render(context)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
DeveloperPortal::Swagger::SpecController#swagger_spec_for performs a nil-check Open
description: service.description.nil? ? service.name : service.description,
- 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)
Liquid::Drops::User#roles_collection doesn't depend on instance state (maybe move it to another class?) Open
def roles_collection
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Tags::Debug#help doesn't depend on instance state (maybe move it to another class?) Open
def help(assigns)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
CMS::Handler::Textile#convert doesn't depend on instance state (maybe move it to another class?) Open
def convert(markup)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Drops::I18n#default_time doesn't depend on instance state (maybe move it to another class?) Open
def default_time
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
CMS::Toolbar::Renderer#layout is a writable attribute Open
attr_writer :layout
- Read upRead up
- Exclude checks
A class that publishes a setter for an instance variable invites client classes to become too intimate with its inner workings, and in particular with its representation of state.
The same holds to a lesser extent for getters, but Reek doesn't flag those.
Example
Given:
class Klass
attr_accessor :dummy
end
Reek would emit the following warning:
reek test.rb
test.rb -- 1 warning:
[2]:Klass declares the writable attribute dummy (Attribute)
Liquid::Assigns#assign_drops performs a nil-check Open
next if drop.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)
Liquid::Filters::RailsHelpers#link_to doesn't depend on instance state (maybe move it to another class?) Open
def link_to(text, path, html_options = {})
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Filters::RailsHelpers#group_by doesn't depend on instance state (maybe move it to another class?) Open
def group_by(collection, key)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.
Liquid::Filters::RailsHelpers#mail_to doesn't depend on instance state (maybe move it to another class?) Open
def mail_to(mail)
- Read upRead up
- Exclude checks
A Utility Function is any instance method that has no dependency on the state of the instance.