codebar/planner

  def create
    @workshop = Workshop.new(workshop_params)
    authorize(@workshop)

    if workshop_type_valid? && @workshop.save

Close

Checks that the ABC size of methods is not higher than the configured maximum. The ABC size is based on assignments, branches (method calls), and conditions. See http://c2.com/cgi/wiki?AbcMetric and https://en.wikipedia.org/wiki/ABC_Software_Metric.

Interpreting ABC size:

• <= 17 satisfactory
• 18..30 unsatisfactory
• > 30 dangerous

You can have repeated "attributes" calls count as a single "branch". For this purpose, attributes are any method with no argument; no attempt is meant to distinguish actual attr_reader from other methods.

Example: CountRepeatedAttributes: false (default is true)

# `model` and `current_user`, referenced 3 times each,
 # are each counted as only 1 branch each if
 # `CountRepeatedAttributes` is set to 'false'

 def search
   @posts = model.active.visible_by(current_user)
             .search(params[:q])
   @posts = model.some_process(@posts, current_user)
   @posts = model.another_process(@posts, current_user)

   render 'pages/search/page'
 end

This cop also takes into account AllowedMethods (defaults to []) And AllowedPatterns (defaults to [])

  def set_host(host_id)

Close

Makes sure that accessor methods are named properly. Applies to both instance and class methods.

NOTE: Offenses are only registered for methods with the expected arity. Getters (get_attribute) must have no arguments to be registered, and setters (set_attribute(value)) must have exactly one.

Example:

# bad
def set_attribute(value)
end

# good
def attribute=(value)
end

# bad
def get_attribute
end

# good
def attribute
end

# accepted, incorrect arity for getter
def get_value(attr)
end

# accepted, incorrect arity for setter
def set_value
end

      @workshop_sponsor ||= WorkshopSponsor.new(workshop: @workshop, sponsor: @sponsor, host: host)

Close

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}

    @invitation = Invitation.find_or_create_by(event: @event, member: current_user, role: role)

Close

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}

      amount: amount,

Close

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}

  def rsvp
    unless @workshop.available_for_rsvp?
      return redirect_back(
        fallback_location: root_path,
        notice: t('workshops.registration_not_open')

Close

Checks that the ABC size of methods is not higher than the configured maximum. The ABC size is based on assignments, branches (method calls), and conditions. See http://c2.com/cgi/wiki?AbcMetric and https://en.wikipedia.org/wiki/ABC_Software_Metric.

Interpreting ABC size:

• <= 17 satisfactory
• 18..30 unsatisfactory
• > 30 dangerous

You can have repeated "attributes" calls count as a single "branch". For this purpose, attributes are any method with no argument; no attempt is meant to distinguish actual attr_reader from other methods.

Example: CountRepeatedAttributes: false (default is true)

# `model` and `current_user`, referenced 3 times each,
 # are each counted as only 1 branch each if
 # `CountRepeatedAttributes` is set to 'false'

 def search
   @posts = model.active.visible_by(current_user)
             .search(params[:q])
   @posts = model.some_process(@posts, current_user)
   @posts = model.another_process(@posts, current_user)

   render 'pages/search/page'
 end

This cop also takes into account AllowedMethods (defaults to []) And AllowedPatterns (defaults to [])

  has_and_belongs_to_many :chapters, join_table: 'chapters_events'

Close

This cop checks for the use of the hasandbelongstomany macro.

Example:

# bad
# has_and_belongs_to_many :ingredients

# good
# has_many :ingredients, through: :recipe_ingredients

  def set_organisers(organiser_ids)

Close

Makes sure that accessor methods are named properly. Applies to both instance and class methods.

NOTE: Offenses are only registered for methods with the expected arity. Getters (get_attribute) must have no arguments to be registered, and setters (set_attribute(value)) must have exactly one.

Example:

# bad
def set_attribute(value)
end

# good
def attribute=(value)
end

# bad
def get_attribute
end

# good
def attribute
end

# accepted, incorrect arity for getter
def get_value(attr)
end

# accepted, incorrect arity for setter
def set_value
end

  def set_organisers(organiser_ids)

Close

Makes sure that accessor methods are named properly. Applies to both instance and class methods.

NOTE: Offenses are only registered for methods with the expected arity. Getters (get_attribute) must have no arguments to be registered, and setters (set_attribute(value)) must have exactly one.

Example:

# bad
def set_attribute(value)
end

# good
def attribute=(value)
end

# bad
def get_attribute
end

# good
def attribute
end

# accepted, incorrect arity for getter
def get_value(attr)
end

# accepted, incorrect arity for setter
def set_value
end

      if current_service

Close

If the else branch of a conditional consists solely of an if node, it can be combined with the else to become an elsif. This helps to keep the nesting level from getting too deep.

Example:

# bad
if condition_a
  action_a
else
  if condition_b
    action_b
  else
    action_c
  end
end

# good
if condition_a
  action_a
elsif condition_b
  action_b
else
  action_c
end

Example: AllowIfModifier: false (default)

# bad
if condition_a
  action_a
else
  action_b if condition_b
end

# good
if condition_a
  action_a
elsif condition_b
  action_b
end

Example: AllowIfModifier: true

# good
if condition_a
  action_a
else
  action_b if condition_b
end

# good
if condition_a
  action_a
elsif condition_b
  action_b
end

    before_action :set_workshop, only: %i[sponsor destroy_sponsor host destroy_host]

Close

This cop checks that methods specified in the filter's only or except options are defined within the same class or module.

You can technically specify methods of superclass or methods added by mixins on the filter, but these can confuse developers. If you specify methods that are defined in other classes or modules, you should define the filter in that class or module.

If you rely on behaviour defined in the superclass actions, you must remember to invoke super in the subclass actions.

Example:

# bad
class LoginController < ApplicationController
  before_action :require_login, only: %i[index settings logout]

  def index
  end
end

# good
class LoginController < ApplicationController
  before_action :require_login, only: %i[index settings logout]

  def index
  end

  def settings
  end

  def logout
  end
end

Example:

# bad
module FooMixin
  extend ActiveSupport::Concern

  included do
    before_action proc { authenticate }, only: :foo
  end
end

# good
module FooMixin
  extend ActiveSupport::Concern

  included do
    before_action proc { authenticate }, only: :foo
  end

  def foo
    # something
  end
end

Example:

class ContentController < ApplicationController
  def update
    @content.update(content_attributes)
  end
end

class ArticlesController < ContentController
  before_action :load_article, only: [:update]

  # the cop requires this method, but it relies on behaviour defined
  # in the superclass, so needs to invoke `super`
  def update
    super
  end

  private

  def load_article
    @content = Article.find(params[:article_id])
  end
end

      @workshop.workshop_sponsors.find_by(host: true).update_attribute(:host, false)

Close

This cop checks for the use of methods which skip validations which are listed in https://guides.rubyonrails.org/active_record_validations.html#skipping-validations

Methods may be ignored from this rule by configuring a Whitelist.

Example:

# bad
Article.first.decrement!(:view_count)
DiscussionBoard.decrement_counter(:post_count, 5)
Article.first.increment!(:view_count)
DiscussionBoard.increment_counter(:post_count, 5)
person.toggle :active
product.touch
Billing.update_all("category = 'authorized', author = 'David'")
user.update_attribute(:website, 'example.com')
user.update_columns(last_request_at: Time.current)
Post.update_counters 5, comment_count: -1, action_count: 1

# good
user.update(website: 'example.com')
FileUtils.touch('file')

Example: Whitelist: ["touch"]

# bad
DiscussionBoard.decrement_counter(:post_count, 5)
DiscussionBoard.increment_counter(:post_count, 5)
person.toggle :active

# good
user.touch

      invitation = WorkshopInvitation.create(workshop: workshop, member: member, role: role)

Close

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}

      invitation = Invitation.new(event: event, member: coach, role: 'Coach')

Close

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}

  has_many :meeting_invitations

Close

This cop looks for has_many or has_one associations that don't specify a :dependent option. It doesn't register an offense if :through option was specified.

Example:

# bad
class User < ActiveRecord::Base
  has_many :comments
  has_one :avatar
end

# good
class User < ActiveRecord::Base
  has_many :comments, dependent: :restrict_with_exception
  has_one :avatar, dependent: :destroy
  has_many :patients, through: :appointments
end

    invitation = meeting.invitations.find_or_create_by(member: member)

Close

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}

    request.referrer || root_path

Close

This cop checks for consistent uses of request.referer or request.referrer, depending on the cop's configuration.

Example: EnforcedStyle: referer (default)

# bad
request.referrer

# good
request.referer

Example: EnforcedStyle: referrer

# bad
request.referer

# good
request.referrer

    @subscription = Subscription.new(group_id: group_id, member: current_user)

Close

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}

  has_many :attendance_warnings

Close

This cop looks for has_many or has_one associations that don't specify a :dependent option. It doesn't register an offense if :through option was specified.

Example:

# bad
class User < ActiveRecord::Base
  has_many :comments
  has_one :avatar
end

# good
class User < ActiveRecord::Base
  has_many :comments, dependent: :restrict_with_exception
  has_one :avatar, dependent: :destroy
  has_many :patients, through: :appointments
end