common_rubocop_rails.yml in radius-spec-0.3.0 vs common_rubocop_rails.yml in radius-spec-0.4.0
- old
+ new
@@ -25,10 +25,11 @@
Documentation:
Enabled: false
Metrics/BlockLength:
Exclude:
+ - 'config/routes.rb'
- 'spec/rails_helper.rb'
# Rails foreign keys and indexes can get long. We want to ignore our annotation
# comments which are for these entries.
#
@@ -37,10 +38,56 @@
Metrics/LineLength:
IgnoredPatterns:
- '\A# fk_rails_'
- '\A# index_'
+# For our Rails apps several of them use the `respond_to` with `format` blocks
+# to handle various mime types (mostly HTML and JSON). Given our `do` / `end`
+# block style for non-functional blocks (which includes both `respond_to` and
+# `format`) the general method limit of is too small. This also applies to the
+# helper methods which define the allowed parameters for the action; especially
+# for larger forms.
+#
+# Here is an example of a minimal controller `update` method which uses the
+# `respond_to` style to support just the HTML and JSON formats:
+#
+# ```ruby
+# def update
+# respond_to do |format|
+# if @resource.update(resource_params)
+# format.html do
+# redirect_to resources_url, notice: 'Resource was successfully updated.'
+# end
+# format.json do
+# render :show, status: :ok, location: @resource
+# end
+# else
+# format.html do
+# render :edit
+# end
+# format.json do
+# render json: @resource.errors, status: :unprocessable_entity
+# end
+# end
+# end
+# end
+# ```
+#
+# We do believe that the default size of 10, which is what we explicitly
+# configure below so there's no confusion, is a good general limit to help
+# encourage a balance between terseness and procedural code. Thus we do not
+# want to raise the limit, instead we just want to exclude these controllers.
+#
+# At this time there is no way for us to exclude just the common controller
+# actions / *_params methods so we exclude the entire file.
+#
+# Configuration parameters: CountComments.
+Metrics/MethodLength:
+ Max: 10
+ Exclude:
+ - 'app/controllers/**/*_controller.rb'
+
# Ignore subclass parent for one off benchmarks
#
# Benchmarks are generally meant to be small and targeted. They often have
# custom model declarations which help direct the focus of the benchmarks.
# These one-off models exist outside of the main Rails app. We don't want this
@@ -57,15 +104,24 @@
# Configuration parameters: Include.
# Include: db/migrate/*.rb
Rails/CreateTableWithTimestamps:
Enabled: false
-# The ActiveSupport monkey patches for `present?` are nearly all defiend as:
+# We understand the trade-offs for using the through model versus a lookup
+# table. As such this cop is just noise as it flags only those cases we really
+# do want a lookup table.
#
+# Configuration parameters: Include.
+# Include: app/models/**/*.rb
+Rails/HasAndBelongsToMany:
+ Enabled: false
+
+# The ActiveSupport monkey patches for `present?` are nearly all defined as:
+#
# !blank?
#
-# For most of use `unless blank?` reads just as easily as `if present?`.
+# For most of us `unless blank?` reads just as easily as `if present?`.
# Sometimes contextually, it can read better depending on the branch logic and
# surrounding context. As `if present?` requires an additional negation and
# method call it is technically slower. In the general case the perf different
# isn't much but in some cases it matters. Thus, we are not enforcing changing
# `unless blank?` to `if present?` and are leaving it up to the context to
@@ -77,10 +133,10 @@
UnlessBlank: false
# We prefer you use the attribute readers and writes. For those special cases
# where the intent is really to interact with the raw underlying attribute we
# prefer `read_attribute` and `write_attribute`; as this makes the intent
-# explict. Ideally we'd never use the hash like accessor `[:attr]`.
+# explicit. Ideally we'd never use the hash like accessor `[:attr]`.
#
# We disable this cop because it is not configurable.
#
# Configuration parameters: Include.
# Include: app/models/**/*.rb