Show why snake_case errors is emitted on single word variables (might be too small)

[rmullin7286]

Steps to reproduce

no = 'No'

Current behavior

I'm getting an error saying that 'no' doesn't conform the camel_case style, even though it's only one word.

Expected behavior

There should be no error.

pylint --version output

pylint 1.8.4,
astroid 1.6.3
Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)]

[PCManticore]

Hi, thanks for creating this issue! Can you also post your pylintrc file? You could also run pylint with --include-naming-hint=y, which will offer more indication on why it considers it a bad name. I think it might be because the name it's too short, by default we expect words of length 3+.

[eight04]

Is there a way to configure the minimum length of the variable name?

[PCManticore]

@eight04 Not quite, the only thing you could do is to change the variable-rgx to conform to the format and length you require. It might be a good idea to just separate the length of a variable/name in pylint from the format of a variable/name.

[gitaarik]

I tried setting variable-rgx, but the invalid-name snake_case error doesn't go away. The variable-rgx setting does work for variables that really don't conform to the regex, but it doesn't take away the first warning, although the docs say that it should override the variable-naming-style setting. When I try to unset it with: variable-naming-style= then both errors go away. All by all, it doesn't make any difference for me.

pylint 2.1.1
astroid 2.0.4
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0]

EDIT:

Oh I found out, I got this error for a function argument, and that's a different option:

argument-rgx=^[a-z][a-z0-9]*((_[a-z0-9]+)*)?$

This works for me :)!

[filips123]

Why is variable length important at all?
Variable can have good name even if it is short. Example for this can be no and some physical variables and constants.
What else can be done excluding changing variable-rgx? One name that conform this style is var_no, but is even worse then just no.

[pedro-w]

I agree with @filips123 - I've been using Python to do physics calculations and I use vars like m, x and y to match the equations. It looks strange and wordy to have to rename them mass, x_coordinate etc.
One option is to use the good-names= config item but it's a bit tedious to maintain in practice.

[PCManticore]

@pedro-w and @filips123 If variable-rgx or good-names is not good for you, you can also disable the check locally in places where you get this error. I don't think x m and similar variable names are readable to other people other than the one that wrote the code, so be mindful of this aspect as well. As it's mentioned in the documentation, pylint is not a one size fits it all, if something does not work for you, feel free to disable / adapt it to your needs.

[filips123]

Is it possible to specify variable-rgx or good-names in file (with inline comment) without pylintrc file?

[PCManticore]

No, that's not possible.

[filips123]

Why? Can you add support for this? It would be useful if only one file contains that variables.

[PCManticore]

Because it requires changing how we do configuration, it's a high effort project that is not worth it for almost all the cases.

[matkoniecz]

To give more specific solution for people who will run into this bug:

pylint t.py --variable-rgx=^[a-z][a-z0-9]*((_[a-z0-9]+)*)?$ --argument-rgx=^[a-z][a-z0-9]*((_[a-z0-9]+)*)?$

will stop complaining about perfectly good names. BTW, it would be nice to have solution similar to Rubocop config files - where it is easy to exclude complaints about names that make perfect sense (and some like x and y are predefined)

See matkoniecz/matkoniecz-ruby-style@e2df9de (how people may configure allowed names) and rubocop/rubocop#6137 "Allow db to allowed names of Naming/UncommunicativeMethodParamName cop in default config"