kirushik/critical_chain

View on GitHub
app/controllers/application_controller.rb

Summary

Maintainability
A
0 mins
Test Coverage

ApplicationController has no descriptive comment
Open

class ApplicationController < ActionController::Base

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

ApplicationController#new_session_path has unused parameter 'scope'
Open

  def new_session_path scope

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)

Missing frozen string literal comment.
Open

class ApplicationController < ActionController::Base

Helps you transition from mutable string literals to frozen string literals. It will add the # frozen_string_literal: true magic comment to the top of files to enable frozen string literals. Frozen string literals may be default in future Ruby. The comment will be added below a shebang and encoding comment. The frozen string literal comment is only valid in Ruby 2.3+.

Note that the cop will accept files where the comment exists but is set to false instead of true.

To require a blank line after this comment, please see Layout/EmptyLineAfterMagicComment cop.

Safety:

This cop's autocorrection is unsafe since any strings mutations will change from being accepted to raising FrozenError, as all strings will become frozen by default, and will need to be manually refactored.

Example: EnforcedStyle: always (default)

# The `always` style will always add the frozen string literal comment
# to a file, regardless of the Ruby version or if `freeze` or `<<` are
# called on a string literal.
# bad
module Bar
  # ...
end

# good
# frozen_string_literal: true

module Bar
  # ...
end

# good
# frozen_string_literal: false

module Bar
  # ...
end

Example: EnforcedStyle: never

# The `never` will enforce that the frozen string literal comment does
# not exist in a file.
# bad
# frozen_string_literal: true

module Baz
  # ...
end

# good
module Baz
  # ...
end

Example: EnforcedStyle: always_true

# The `always_true` style enforces that the frozen string literal
# comment is set to `true`. This is a stricter option than `always`
# and forces projects to use frozen string literals.
# bad
# frozen_string_literal: false

module Baz
  # ...
end

# bad
module Baz
  # ...
end

# good
# frozen_string_literal: true

module Bar
  # ...
end

Use def with parentheses when there are parameters.
Open

  def new_session_path scope

Checks for parentheses around the arguments in method definitions. Both instance and class/singleton methods are checked.

Regardless of style, parentheses are necessary for:

  1. Endless methods
  2. Argument lists containing a forward-arg (...)
  3. Argument lists containing an anonymous rest arguments forwarding (*)
  4. Argument lists containing an anonymous keyword rest arguments forwarding (**)
  5. Argument lists containing an anonymous block forwarding (&)

Removing the parens would be a syntax error here.

Example: EnforcedStyle: require_parentheses (default)

# The `require_parentheses` style requires method definitions
# to always use parentheses

# bad
def bar num1, num2
  num1 + num2
end

def foo descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name
  do_something
end

# good
def bar(num1, num2)
  num1 + num2
end

def foo(descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name)
  do_something
end

Example: EnforcedStyle: requirenoparentheses

# The `require_no_parentheses` style requires method definitions
# to never use parentheses

# bad
def bar(num1, num2)
  num1 + num2
end

def foo(descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name)
  do_something
end

# good
def bar num1, num2
  num1 + num2
end

def foo descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name
  do_something
end

Example: EnforcedStyle: requirenoparenthesesexceptmultiline

# The `require_no_parentheses_except_multiline` style prefers no
# parentheses when method definition arguments fit on single line,
# but prefers parentheses when arguments span multiple lines.

# bad
def bar(num1, num2)
  num1 + num2
end

def foo descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name
  do_something
end

# good
def bar num1, num2
  num1 + num2
end

def foo(descriptive_var_name,
        another_descriptive_var_name,
        last_descriptive_var_name)
  do_something
end

Indent access modifiers like private.
Open

private

Bare access modifiers (those not applying to specific methods) should be indented as deep as method definitions, or as deep as the class/module keyword, depending on configuration.

Example: EnforcedStyle: indent (default)

# bad
class Plumbus
private
  def smooth; end
end

# good
class Plumbus
  private
  def smooth; end
end

Example: EnforcedStyle: outdent

# bad
class Plumbus
  private
  def smooth; end
end

# good
class Plumbus
private
  def smooth; end
end

Use the new Ruby 1.9 hash syntax.
Open

  after_action :verify_authorized, :except => :index, :unless => :devise_controller?

Checks hash literal syntax.

It can enforce either the use of the class hash rocket syntax or the use of the newer Ruby 1.9 syntax (when applicable).

A separate offense is registered for each problematic pair.

The supported styles are:

  • ruby19 - forces use of the 1.9 syntax (e.g. {a: 1}) when hashes have all symbols for keys
  • hash_rockets - forces use of hash rockets for all hashes
  • nomixedkeys - simply checks for hashes with mixed syntaxes
  • ruby19nomixed_keys - forces use of ruby 1.9 syntax and forbids mixed syntax hashes

This cop has EnforcedShorthandSyntax option. It can enforce either the use of the explicit hash value syntax or the use of Ruby 3.1's hash value shorthand syntax.

The supported styles are:

  • always - forces use of the 3.1 syntax (e.g. {foo:})
  • never - forces use of explicit hash literal value
  • either - accepts both shorthand and explicit use of hash literal value
  • consistent - forces use of the 3.1 syntax only if all values can be omitted in the hash

Example: EnforcedStyle: ruby19 (default)

# bad
{:a => 2}
{b: 1, :c => 2}

# good
{a: 2, b: 1}
{:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
{d: 1, 'e' => 2} # technically not forbidden

Example: EnforcedStyle: hash_rockets

# bad
{a: 1, b: 2}
{c: 1, 'd' => 5}

# good
{:a => 1, :b => 2}

Example: EnforcedStyle: nomixedkeys

# bad
{:a => 1, b: 2}
{c: 1, 'd' => 2}

# good
{:a => 1, :b => 2}
{c: 1, d: 2}

Example: EnforcedStyle: ruby19nomixed_keys

# bad
{:a => 1, :b => 2}
{c: 2, 'd' => 3} # should just use hash rockets

# good
{a: 1, b: 2}
{:c => 3, 'd' => 4}

Example: EnforcedShorthandSyntax: always (default)

# bad
{foo: foo, bar: bar}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: never

# bad
{foo:, bar:}

# good
{foo: foo, bar: bar}

Example: EnforcedShorthandSyntax: either

# good
{foo: foo, bar: bar}

# good
{foo: foo, bar:}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: consistent

# bad - `foo` and `bar` values can be omitted
{foo: foo, bar: bar}

# bad - `bar` value can be omitted
{foo:, bar: bar}

# bad - mixed syntaxes
{foo:, bar: baz}

# good
{foo:, bar:}

# good - can't omit `baz`
{foo: foo, bar: baz}

Unused method argument - scope. If it's necessary, use _ or _scope as an argument name to indicate that it won't be used. If it's unnecessary, remove it. You can also write as new_session_path(*) if you want the method to accept any arguments but don't care about them.
Open

  def new_session_path scope

Checks for unused method arguments.

Example:

# bad
def some_method(used, unused, _unused_but_allowed)
  puts used
end

# good
def some_method(used, _unused, _unused_but_allowed)
  puts used
end

Example: AllowUnusedKeywordArguments: false (default)

# bad
def do_something(used, unused: 42)
  used
end

Example: AllowUnusedKeywordArguments: true

# good
def do_something(used, unused: 42)
  used
end

Example: IgnoreEmptyMethods: true (default)

# good
def do_something(unused)
end

Example: IgnoreEmptyMethods: false

# bad
def do_something(unused)
end

Example: IgnoreNotImplementedMethods: true (default)

# good
def do_something(unused)
  raise NotImplementedError
end

def do_something_else(unused)
  fail "TODO"
end

Example: IgnoreNotImplementedMethods: false

# bad
def do_something(unused)
  raise NotImplementedError
end

def do_something_else(unused)
  fail "TODO"
end

Use the new Ruby 1.9 hash syntax.
Open

  after_action :verify_policy_scoped, :only => :index, :unless => :devise_controller?

Checks hash literal syntax.

It can enforce either the use of the class hash rocket syntax or the use of the newer Ruby 1.9 syntax (when applicable).

A separate offense is registered for each problematic pair.

The supported styles are:

  • ruby19 - forces use of the 1.9 syntax (e.g. {a: 1}) when hashes have all symbols for keys
  • hash_rockets - forces use of hash rockets for all hashes
  • nomixedkeys - simply checks for hashes with mixed syntaxes
  • ruby19nomixed_keys - forces use of ruby 1.9 syntax and forbids mixed syntax hashes

This cop has EnforcedShorthandSyntax option. It can enforce either the use of the explicit hash value syntax or the use of Ruby 3.1's hash value shorthand syntax.

The supported styles are:

  • always - forces use of the 3.1 syntax (e.g. {foo:})
  • never - forces use of explicit hash literal value
  • either - accepts both shorthand and explicit use of hash literal value
  • consistent - forces use of the 3.1 syntax only if all values can be omitted in the hash

Example: EnforcedStyle: ruby19 (default)

# bad
{:a => 2}
{b: 1, :c => 2}

# good
{a: 2, b: 1}
{:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
{d: 1, 'e' => 2} # technically not forbidden

Example: EnforcedStyle: hash_rockets

# bad
{a: 1, b: 2}
{c: 1, 'd' => 5}

# good
{:a => 1, :b => 2}

Example: EnforcedStyle: nomixedkeys

# bad
{:a => 1, b: 2}
{c: 1, 'd' => 2}

# good
{:a => 1, :b => 2}
{c: 1, d: 2}

Example: EnforcedStyle: ruby19nomixed_keys

# bad
{:a => 1, :b => 2}
{c: 2, 'd' => 3} # should just use hash rockets

# good
{a: 1, b: 2}
{:c => 3, 'd' => 4}

Example: EnforcedShorthandSyntax: always (default)

# bad
{foo: foo, bar: bar}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: never

# bad
{foo:, bar:}

# good
{foo: foo, bar: bar}

Example: EnforcedShorthandSyntax: either

# good
{foo: foo, bar: bar}

# good
{foo: foo, bar:}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: consistent

# bad - `foo` and `bar` values can be omitted
{foo: foo, bar: bar}

# bad - `bar` value can be omitted
{foo:, bar: bar}

# bad - mixed syntaxes
{foo:, bar: baz}

# good
{foo:, bar:}

# good - can't omit `baz`
{foo: foo, bar: baz}

Missing top-level documentation comment for class ApplicationController.
Open

class ApplicationController < ActionController::Base

Checks for missing top-level documentation of classes and modules. Classes with no body are exempt from the check and so are namespace modules - modules that have nothing in their bodies except classes, other modules, constant definitions or constant visibility declarations.

The documentation requirement is annulled if the class or module has a #:nodoc: comment next to it. Likewise, #:nodoc: all does the same for all its children.

Example:

# bad
class Person
  # ...
end

module Math
end

# good
# Description/Explanation of Person class
class Person
  # ...
end

# allowed
  # Class without body
  class Person
  end

  # Namespace - A namespace can be a class or a module
  # Containing a class
  module Namespace
    # Description/Explanation of Person class
    class Person
      # ...
    end
  end

  # Containing constant visibility declaration
  module Namespace
    class Private
    end

    private_constant :Private
  end

  # Containing constant definition
  module Namespace
    Public = Class.new
  end

  # Macro calls
  module Namespace
    extend Foo
  end

Example: AllowedConstants: ['ClassMethods']

# good
 module A
   module ClassMethods
     # ...
   end
  end

Use the new Ruby 1.9 hash syntax.
Open

  after_action :verify_policy_scoped, :only => :index, :unless => :devise_controller?

Checks hash literal syntax.

It can enforce either the use of the class hash rocket syntax or the use of the newer Ruby 1.9 syntax (when applicable).

A separate offense is registered for each problematic pair.

The supported styles are:

  • ruby19 - forces use of the 1.9 syntax (e.g. {a: 1}) when hashes have all symbols for keys
  • hash_rockets - forces use of hash rockets for all hashes
  • nomixedkeys - simply checks for hashes with mixed syntaxes
  • ruby19nomixed_keys - forces use of ruby 1.9 syntax and forbids mixed syntax hashes

This cop has EnforcedShorthandSyntax option. It can enforce either the use of the explicit hash value syntax or the use of Ruby 3.1's hash value shorthand syntax.

The supported styles are:

  • always - forces use of the 3.1 syntax (e.g. {foo:})
  • never - forces use of explicit hash literal value
  • either - accepts both shorthand and explicit use of hash literal value
  • consistent - forces use of the 3.1 syntax only if all values can be omitted in the hash

Example: EnforcedStyle: ruby19 (default)

# bad
{:a => 2}
{b: 1, :c => 2}

# good
{a: 2, b: 1}
{:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
{d: 1, 'e' => 2} # technically not forbidden

Example: EnforcedStyle: hash_rockets

# bad
{a: 1, b: 2}
{c: 1, 'd' => 5}

# good
{:a => 1, :b => 2}

Example: EnforcedStyle: nomixedkeys

# bad
{:a => 1, b: 2}
{c: 1, 'd' => 2}

# good
{:a => 1, :b => 2}
{c: 1, d: 2}

Example: EnforcedStyle: ruby19nomixed_keys

# bad
{:a => 1, :b => 2}
{c: 2, 'd' => 3} # should just use hash rockets

# good
{a: 1, b: 2}
{:c => 3, 'd' => 4}

Example: EnforcedShorthandSyntax: always (default)

# bad
{foo: foo, bar: bar}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: never

# bad
{foo:, bar:}

# good
{foo: foo, bar: bar}

Example: EnforcedShorthandSyntax: either

# good
{foo: foo, bar: bar}

# good
{foo: foo, bar:}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: consistent

# bad - `foo` and `bar` values can be omitted
{foo: foo, bar: bar}

# bad - `bar` value can be omitted
{foo:, bar: bar}

# bad - mixed syntaxes
{foo:, bar: baz}

# good
{foo:, bar:}

# good - can't omit `baz`
{foo: foo, bar: baz}

Use the new Ruby 1.9 hash syntax.
Open

  after_action :verify_authorized, :except => :index, :unless => :devise_controller?

Checks hash literal syntax.

It can enforce either the use of the class hash rocket syntax or the use of the newer Ruby 1.9 syntax (when applicable).

A separate offense is registered for each problematic pair.

The supported styles are:

  • ruby19 - forces use of the 1.9 syntax (e.g. {a: 1}) when hashes have all symbols for keys
  • hash_rockets - forces use of hash rockets for all hashes
  • nomixedkeys - simply checks for hashes with mixed syntaxes
  • ruby19nomixed_keys - forces use of ruby 1.9 syntax and forbids mixed syntax hashes

This cop has EnforcedShorthandSyntax option. It can enforce either the use of the explicit hash value syntax or the use of Ruby 3.1's hash value shorthand syntax.

The supported styles are:

  • always - forces use of the 3.1 syntax (e.g. {foo:})
  • never - forces use of explicit hash literal value
  • either - accepts both shorthand and explicit use of hash literal value
  • consistent - forces use of the 3.1 syntax only if all values can be omitted in the hash

Example: EnforcedStyle: ruby19 (default)

# bad
{:a => 2}
{b: 1, :c => 2}

# good
{a: 2, b: 1}
{:c => 2, 'd' => 2} # acceptable since 'd' isn't a symbol
{d: 1, 'e' => 2} # technically not forbidden

Example: EnforcedStyle: hash_rockets

# bad
{a: 1, b: 2}
{c: 1, 'd' => 5}

# good
{:a => 1, :b => 2}

Example: EnforcedStyle: nomixedkeys

# bad
{:a => 1, b: 2}
{c: 1, 'd' => 2}

# good
{:a => 1, :b => 2}
{c: 1, d: 2}

Example: EnforcedStyle: ruby19nomixed_keys

# bad
{:a => 1, :b => 2}
{c: 2, 'd' => 3} # should just use hash rockets

# good
{a: 1, b: 2}
{:c => 3, 'd' => 4}

Example: EnforcedShorthandSyntax: always (default)

# bad
{foo: foo, bar: bar}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: never

# bad
{foo:, bar:}

# good
{foo: foo, bar: bar}

Example: EnforcedShorthandSyntax: either

# good
{foo: foo, bar: bar}

# good
{foo: foo, bar:}

# good
{foo:, bar:}

Example: EnforcedShorthandSyntax: consistent

# bad - `foo` and `bar` values can be omitted
{foo: foo, bar: bar}

# bad - `bar` value can be omitted
{foo:, bar: bar}

# bad - mixed syntaxes
{foo:, bar: baz}

# good
{foo:, bar:}

# good - can't omit `baz`
{foo: foo, bar: baz}

There are no issues that match your filters.

Category
Status