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