We were already applying the FindEach rule since commit cae210c1, while
the EnumUniqueness rule is essential when we use `enum`, and the
EnvironmentComparison rule is very useful since it forces us to use a
format the UnknownEnv rule will recognize.
While I don't use this feature, there are developers who do. It's useful
when running migrations and changing branches.
I'm raising an `ActiveRecord::IrreversibleMigration` exception in every
`drop_table` migration because these migrations were all done before
version 1.0.0, and so making all of them reversible would be too much
work for little benefit.
These are rules we can't apply to existing migrations, so I'm excluding
migrations in the affected years from this check. However, we should
probably add timestamps columns and default values in non-null columns
to at least some of the tables which don't have them.
We were using the `timestamps` method most of the time, but sometimes we
were creating the columns manually.
Note editing past migrations if fine as long as the SQL they generate
remains identical, which is the case here.
There are some rules which only affect migration files, and we cannot
enable them if we're excluding those files from being inspected.
We're also changing migrations related to the Rails/TimeZone rule
slightly because these fields were already changed afterwards, so we
aren't changing the schema.
This comment isn't necessary since Ruby 2.0, where UTF-8 became the
default encoding.
I've found this issue thanks to the EmptyLineAfterMagicComment rubocop
rule.
We were inconsistent on this one. I consider it particularly useful when
a method starts with a `return` statement.
In other cases, we probably shouldn't have a guard rule in the middle of
a method in any case, but that's a different refactoring.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
We were already using `find_by` most of the time.
Since there are false positives related to our `find_by_slug_or_id!` and
`find_by_manger_login` methods, which cannot be replaced with `find_by`,
I'm adding it indicating the "refactor" severity.
In Ruby, the Kernel class defined the `open` method, which is available
for (almost) every object. So creating a scope with the name `open`
generates a warning indicating we are overwriting the existing `open`
method.
While this warning is pretty much harmless and we could ignore it, it
generates a lot of noise in the logs. So I'm "undefining" the method
before generating the scope, so we don't get the warning all the time.
It looks like we get this warning if we check the dialog message. Using
`accept_confirm` the same way we do in the rest of the application
solves the problem.
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.
This will be the default behaviour in Rails 5.1, and it's a much better
approach.
I've checked the code and luckily there doesn't seem to be a single
place where we could accidentally stop the callback chain by returning
false in (for example) a `before_save` callback.
