3scale/porta

View on GitHub

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

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 """

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

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 """

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!

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?

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)

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

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

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)

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,

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

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)

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)

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

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

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?

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 = {})

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)

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)

A Utility Function is any instance method that has no dependency on the state of the instance.

Severity
Category
Status
Source
Language