You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using # rubocop:disable Style/NumericLiterals inline, works fine when running rubocop.
However, the length of the disabled literal is used by the logic that creates .rubocop_todo.yml file. This is a problem when the literal that has been excluded for the cop is longer than the existing value of MinDigits in the todo file. This means that the MinDigits parameter can get set to something larger than is desired, which eventually means it's impossible to use # rubocop:disable Style/NumericLiterals on numbers that are longer than MinDigits as I go on to describe.
Expected behavior
Running rubocop --regenerate-todo should not change the MaxLength value.
Actual behavior
Running rubocop --regenerate-todo increases the value of MinDigits to be one more than the length of the literal that we have instructed the Style/NumericLiterals to ignore.
This then leads to follow-up problems - the next run of rubocop will not be green due to an un-necessary disable comment being detected, and removing the disable comment is undesirable as we intended to mark that specific literal is being OK.
Steps to reproduce the problem
Create a 10 digit constant somewhere FIRST_VIOLATION = 1234567890
Run rubocop --regenerate-todo which should generate something like
Run rubocop and it doesn't run succesfully - it tells you the disable is no longer required.
Remove the inline disable and rubocop will return green. However, now the special case which we want to allow, is no longer explicitly allowed and is now part of the todo file.
The workaround I'm using for this is for now to Exclude the whole file in rubocop.yml - this is respected by the todo generation code. So it looks like this problem is specific to when a cop is disabled inline.
Using
# rubocop:disable Style/NumericLiterals
inline, works fine when runningrubocop
.However, the length of the disabled literal is used by the logic that creates
.rubocop_todo.yml
file. This is a problem when the literal that has been excluded for the cop is longer than the existing value ofMinDigits
in thetodo
file. This means that theMinDigits
parameter can get set to something larger than is desired, which eventually means it's impossible to use# rubocop:disable Style/NumericLiterals
on numbers that are longer thanMinDigits
as I go on to describe.Expected behavior
Running
rubocop --regenerate-todo
should not change theMaxLength
value.Actual behavior
Running
rubocop --regenerate-todo
increases the value ofMinDigits
to be one more than the length of the literal that we have instructed theStyle/NumericLiterals
to ignore.This then leads to follow-up problems - the next run of
rubocop
will not be green due to an un-necessarydisable
comment being detected, and removing thedisable
comment is undesirable as we intended to mark that specific literal is being OK.Steps to reproduce the problem
FIRST_VIOLATION = 1234567890
rubocop --regenerate-todo
which should generate something likerubocop
and everything is green. It's all good and as desired up to this point.rubocop --regenerate-todo
again. It will get updated torubocop
and it doesn't run succesfully - it tells you thedisable
is no longer required.disable
andrubocop
will return green. However, now the special case which we want to allow, is no longer explicitly allowed and is now part of thetodo
file.RuboCop version
The text was updated successfully, but these errors were encountered: