Pylint: 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 https://github.com/matkoniecz/matkoniecz-ruby-style/commit/e2df9deba34054e86d40669416c716a3d67bfd51 (how people may configure allowed names) and https://github.com/rubocop-hq/rubocop/pull/6137 "Allow db to allowed names of Naming/UncommunicativeMethodParamName cop in default config"

[PCManticore]

@matkoniecz That's most likely an use case for good-names

[blaiseli]

Reading the above discussion, I learned about the good-names option, and I'm grateful for it, but I'm not sure I understand whether something is already under way to change the way pylint reports about short variable names or not, and if yes, what will be the new behaviour.

I'm using a freshly installed pylint (using pip under python3.7):

$ pylint --version
pylint 2.4.2
astroid 2.3.1
Python 3.7.2 (default, Mar  6 2019, 18:38:11) 
[GCC 4.9.0]

With this version, variable name fh gets caught as Variable name "fh" doesn't conform to snake_case naming style. f_h does not (which I indeed consider snake_case, so everything fine here), but fhh too does not trigger a message. This means that (fortunately) the use of underscore is not mandatory. So the problem with fh is not really that it is not snake_case, but that it is too short.

I may be remembering wrong, but it seems to me that some time ago, pylint would not report about snake_case naming style in the case of short variable names, but either more generally, about bad naming style, or more precisely, about the shortness of the name. I would argue the latter would be desirable as new behaviour. But maybe it is complicated to obtain if the names are checked against just one "one-size-fits-all" regexp.

[demongolem]

I just ask a clarification. I thought it was standard name to use f for file objects and hence I am getting these warnings in a few different places. Would there be a more acceptable name for a file object, or do I somehow have to deal with these myself?

[chrissshe]

@demongolem Reading above, I think you just need to somehow have to deal with these myself, which is really straightforward.

Add f to good-names See reference at http://pylint.pycqa.org/en/latest/technical_reference/features.html?highlight=good-names#basic-checker-options

[chrissshe]

I got this warning even for stuff like for i in range(100) . Does pylint advise against using i?

[PCManticore]

@chrissshe Not by default, i is a permitted name among other, but you might have overwritten the default good-names list of permitted names if you are still getting this error for i.

[chrissshe]

@PCManticore That's probably the case. I edited good-names to allow df (dataframe)

[prjemian]

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

I understand that it may be a high effort project, thus remain patient for it to stay on the long-term road map for implementation. The remark about not worth it for almost all the cases is opinion and is at odds with a substantial community.

In physics, common coding practice will often adopt names used in textbooks or published literature as being best choice. These names are recognized internationally, even though they rely on domain-specific jargon, it is exactly the entirety of that community they reach.

As we recommend value-added steps, such as linting, to coding practice for our non-programmer peers, we must advise them which of these findings to either heed or ignore. For sure, none of these pylint novices will apply local configurations or regexp rules. As it stands now, a pylint report is rife with such false positive findings. We insist to our novices that these reports are only advisory.

A command-line option would be of great benefit to a significant community.

[PCManticore]

@prjemian Thanks for the comment, but I'm not sure why --good-names is not enough for you at this point? If f, df or whatever name you want to use still emits this error, simply passing --good-names=f,df to pylint should be enough to remove the error, without using a local configuration, nor regexp rule.

Also I'm not sure you're quoting me on the right context. The quoted answer was related to https://github.com/PyCQA/pylint/issues/2018#issuecomment-454777916, which suggests to add inline comments for good-names and similar options, which as far as I can tell, will not happen anytime soon, hence the too much effort comment of a change that is not worth doing.

I'm not sure what your comment is suggesting though. Is it the inline comment support? Is it something else? Right now this issue is about showing why a short variable might not match the naming style, namely because it is too short, not because it does not match the chosen naming style.

[prjemian]

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

@PCManticore : This was your quote, right?

I missed that it referred to markup in the python file that identified potential good names.

---

Thanks to your reply, investigated further the --good-names option and agree that it will work. Requires at least one pass to identify the flagged names, then exclude them, such as:

(py37) jemian@wow ~/.../projects/xpcs-nexus-8idi $ pylint load_xpcs_result.py
************* Module load_xpcs_result
load_xpcs_result.py:19:42: C0103: Variable name "f" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:20:8: C0103: Variable name "Iq" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:23:8: C0103: Variable name "t0" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:25:8: C0103: Variable name "g2" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:27:8: C0103: Variable name "Int_2D" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:50:8: C0103: Variable name "ii" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:51:12: C0103: Variable name "jj" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:53:12: C0103: Variable name "ax" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:79:4: C0103: Variable name "QZ_colormap" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:82:9: C0103: Variable name "ax" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:83:4: C0103: Variable name "im" doesn't conform to snake_case naming style (invalid-name)
load_xpcs_result.py:99:10: C0103: Variable name "ax" doesn't conform to snake_case naming style (invalid-name)

-------------------------------------------------------------------
Your code has been rated at 7.89/10 (previous run: 10.00/10, -2.11)

(py37) jemian@wow ~/.../projects/xpcs-nexus-8idi $ pylint --good-names "Int_2D, f, Iq, t0, g2, ii, jj, ax, im, QZ_colormap" load_xpcs_result.py 

-------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 7.89/10, +2.11)

That's about as good as I can hope for.

[alexchandel]

--good-names is insufficient because pylint is frequently invoked on large collections of files (including package files) by IDEs. A setting to disable the minimum length of 3 is needed, and there's clearly enormous demand for this.

[dcsanx]

there are some names in the standard library that are camelCase eg like maxDiff
is the workaround to add these to 'good-names` ?

[graciejane]

A setting to disable the minimum length of 3 is needed, and there's clearly enormous demand for this.

Completely agree with this. A simple configuration option to set the minimum length will save a lot of annoying warnings and workarounds. Or at least make a separate warning to say it's too short (so we can quickly ignore it) instead of not conforming to snake case which is misleading.

[Toxe]

Completely agree with this. A simple configuration option to set the minimum length will save a lot of annoying warnings and workarounds. Or at least make a separate warning to say it's too short (so we can quickly ignore it) instead of not conforming to snake case which is misleading.

Agreed. Just disable a "minimum length" option per default and let people choose what fits their needs best. No one is forced to use it and this should make everyone happy.

_Edit:_ Also, this warning doesn't really make sense for short variable names anyways. Let's say I have a variable called x: How _could_ this even be written in snake_case? x_? _x?

Or two character names like fp or df. How many single letter words are there in latin languages that could be combined into a snake_case variable name that actually makes sense? Granted, I am not a native English speaker, but I cannot think of one example that would work in English. "AI" maybe, but that is an acronym and doesn't really count, I'd say.

So, if anything there should be a "variable-name-too-short" warning or something like that, but not a warning about something that isn't even possible.

And the other thing is that these short variable names _do make sense_ in certain contexts, for example in math or physics calculations, as @pedro-w already pointed out above. It could actually be a lot more confusing to use longer names in these cases. But ultimately pylint shouldn't really have a strong opinion about this and leave this decision to the users (but provide a good default of course).