| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We added `assert_not` in f75addd "to replace warty 'assert !foo'".
fa8d35b agrees that it is warty, and so do I. This custom Rubocop rule
turns the wart into a violation.
As with my last custom cop, https://github.com/rails/rails/pull/32441,
I want to make sure this looks right on code climate before pushing
another commit to autocorrect everything.
@toshimaru I just noticed
https://github.com/toshimaru/rubocop-rails/pull/26
Is there a better way to add these custom cops, or were you saying we
shouldn't have custom cops at all?
|
|
|
Since at least cf4afc4 we have preferred `assert_not` methods over
`refute` methods. I have seen plenty of comments in PRs about this,
and we have tried to fix it a few times (5294ad8, e45f176, 8910f12,
41f50be, d4cfd54, 48a183e, and 211adb4), but the `refute` methods
keep sneaking back in.
This custom RuboCop will take care of enforcing this preference, so we
don't have to think about it again. I suspect there are other similar
stylistic preferences that could be solved with some custom RuboCops, so
I will definitely keep my eyes open. `assert_not` over `assert !` might
be a good candidate, for example.
I wasn't totally sure if `ci/custom_cops` was the best place to put
this, but nothing else seemed quite right. At one point I had it set up
as a gem, but I think custom cops like this would have limited value
in another context.
I want to see how code climate handles the new cops before
autocorrecting the existing violations. If things go as expected, I will
push another commit with those corrections.
|
