The new VariableNumber cop flags variables like user_name_1 when the enforced style is normalcase. I would imagine that user_name1 would be make the style check pass but this isn't valid either apparently. The only thing I can do to get this to pass with normalcase is userName1 which is odd.
$ cat example.rb
foo_bar1 = 1
$ bundle exec rubocop --only VariableNumber example.rb
Inspecting 1 file
.
1 file inspected, no offenses detected
$ cat example.rb
foo_bar1 = 1
$ bundle exec rubocop --only VariableNumber example.rb
Inspecting 1 file
C
Offenses:
example.rb:1:1: C: Use normalcase for variable numbers.
foo_bar1 = 1
^^^^^^^^
1 file inspected, 1 offense detected
Run the VariableNumber cop against any source file with a variable name which contains an underscore between two words and a trailing number (like foo_bar1).
Include the output of rubocop -V. Here's an example:
$ rubocop -V
0.43.0 (using Parser 2.3.1.3, running on ruby 2.3.1 x86_64-darwin15)
It also thinks expected_h1_text is not a valid variable name.
spec/redacted.rb:109:9: C: Style/VariableNumber: Use normalcase for variable numbers.
expected_h1_text =
^^^^^^^^^^^^^^^^
Yeah @jaredbeck see #3514 for that issue
generic_3_digits is also not a valid variable name. Regards.
Having the same problem with variables ending in _sha1 and _sha256, while variables starting with sha1_ and sha256_ pass the default cop. In my opinion the former should also pass the default cop.
I believe the rule should only apply to how the number is appended to its preceeding text.
So for normalcase:
user1_id # valid
user_1_id # invalid
sha256 # valid
sha_256 #invalid
for snake_case:
user1_id # invalid
user_1_id # valid
sha256 # invalid
sha_256 #valid
Even though, I believe that h1, sha256 and md5 are good examples of "names", that I would never want to snake-case...
The problem is, that the cop only "wants" to address counting (user 1, user 2, etc), but it matches anything that contains a number....
Most helpful comment
It also thinks
expected_h1_textis not a valid variable name.