This rule was added in rubocop-rspec 2.19.0.
When freezing time in a test, `travel_back` is called automatically when
the test finishes, so we can do it in a `before` block instead of an
`around` block.
Note this rule didn't detect our usage of `freeze_time` because we were
using it on cops with a certain tag, but I expect the rule to be able to
detect this usage in the future.
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
We originally added the `cached_votes_up > 0` in commit 4ce95e273
because back then `cached_votes_up` was used in the denominator. That's
no longer the case, and it doesn't make sense to mark a debate with 1
vote and 10 flags as conflictive but not doing it when the debate has no
votes and 1000 flags.
We're fixing the bug right now because we're about to change the
affected line in order to apply a new rubocop rule.
This rule was added in rubocop 1.37.0. It's particularly useful in the
background image spec, since now there's one less backslash to decipher
when reading the code :).
This rule was added in rubocop-rspec 2.12.0, and we were already
following it most of the time.
However, the rule isn't working correctly in some cases, such as input
selectors, so we aren't enabling it.
This rule was added in rubocop-rspec 2.11.0. We aren't adding it
because, out of 3 offenses, this cop can only correct 2 automatically.
Not sure how to correct the other one since it uses `.and change`.
This rule was added in rubocop-rspec 2.9.0.
We were using `be_nil` 50% of the time, and `be nil` the rest of the
time. No strong preference for either one, but IMHO we don't lose
anything be being consistent.
This rule was introduced in rubocop-rails 2.18.0.
Since using `response.parsed_body` is shorter than using
`JSON.parse(response.body)`, this also means we can group some lines in
one.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
Having expectations related to database operations in system tests after
the process running the browser has started might result in exceptions
while running our test suite.
We were already using it in most places.
Note that enabling this rule means we've got to change a few lines in
order to follow the LineEndStringConcatenationIndentation rule. In the
link list tests, the easiest way to do so was to use heredoc instead,
which IMHO improves readability over the previous version.
For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
We were already applying these rules in most cases.
Note we aren't enabling the `MultilineArrayLineBreaks` rule because
we've got places with many elements whire it isn't clear whether
having one element per line would make the code more readable.
Since IRB has improved its support for multiline, the main argument
towars using a trailing dot no longer affects most people.
It still affects me, though, since I use Pry :), but I agree
leading dots are more readable, so I'm enabling the rule anyway.
