Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
The code `where(id: ids)` is equivalent to `where(id: ids.uniq)`.
Since Rails 5 uses `distinct` instead of `uniq` and in most cases where
we use `uniq` with `pluck` we should simply remove the `uniq` call (as
done in this commit), we're also removing the `Rails/UniqBeforePluck`
rubocop rule.
For performance purposes, we need to find bottlenecks in our
application. Optimizing the performance of small methods doesn't make
the application faster.
I've kept a few cops because applying these ones IMHO make the code
easier to read.
These are rules we were already applying.
We've excluded the `factories` folder for some rules because there's a
factory defining a `context` attribute, which rubocop thought was the
`context` RSpec keyword.
We use staging and preproduction environments, which are not valid by
default.
This rule is useful because misspelling the name of an environment might
otherwise go unnoticed.
Using Date.today and Time.now is a common mistake which might lead to
obscure bugs. Now we're making sure we'll receive a warning when a pull
request uses these methods.
The reason for this rule is similar to dynamic factories: we want
dynamic dates to be evaluted relative to the current time, and not
relative to the moment the application was loaded.
Factory bot has stopped supporting dynamic attributes, and we'll have to
change all factories before upgrading.
In order to apply the rubocop rule, we need to bump rubocop-rspec to its
latest version.
These rules are now defined under `Style/`. However, we don't really use
them, so they add noise to the rubocop configuration file without
solving any issues we actually have.
We forgot to add these changes to pull requests which were in
development before we upgraded to Rails 5.
We're also moving the rubocop rules to the basic files, so we're
notified when we inherit from `ActiveRecord::Base`.
We've agreed `User.new` is easier to read than `described_class.new` and
since we are ignoring Hound's comments regarding this topic, we might as
well remove it.
