sponsor
, destroy_sponsor
, host
, destroy_host
are not explicitly defined on the module. Open
before_action :set_workshop, only: %i[sponsor destroy_sponsor host destroy_host]
- Read upRead up
- Exclude checks
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
Avoid using update_attribute
because it skips validations. Open
@workshop.workshop_sponsors.find_by(host: true).update_attribute(:host, false)
- Read upRead up
- Exclude checks
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
sponsor
, host
are not explicitly defined on the module. Open
before_action :set_sponsor, only: %i[sponsor host]
- Read upRead up
- Exclude checks
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
Avoid using update_attribute
because it skips validations. Open
@workshop_sponsor.update_attribute(:host, true)
- Read upRead up
- Exclude checks
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
Use the return of the conditional for variable assignment and comparison. Open
if workshop_sponsors.save
flash[:notice] = 'Sponsor added successfully'
else
flash[:notice] = workshop_sponsors.errors.full_messages.to_s
end
- Exclude checks
Omit the hash value. Open
@workshop_sponsor ||= WorkshopSponsor.new(workshop: @workshop, sponsor: @sponsor, host: host)
- Read upRead up
- Exclude checks
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}