Make Python clean again.
Pylint
is a nice tool for code analysis and it is well documented here. The setup of pylint in Emacs has been discussed in a previous article. Pylint is highly-configurable via the .pylintrc
file.
This article will focus on the tuning of the pylintrc file. The tuning is based on my actual needs.
Disabled messages
The messages are categorized into four groups:
- The “too-many/few” family:
too-many-arguments
,too-many-branches
,too-many-instance-attributes
,too-many-locals
,too-many-public-methods
,too-many-statements
,too-few-public-methods
. Having something “too many” typically indicates the code is not well designed. Yet, how many is “too many”? It really depends and a maximum number given in PEP or pylint may not be practical. Same thing for “too few”. - False-positive:
no-member
,unbalanced-tuple-unpacking
. After all, pylint is not able to actually run the code and identify the variables that are created dynamically or in a context-dependent manner. In these cases, pylint raise distracting false-positive messages. - Code style:
bad-whitespace
,invalid-name
. The PEP does have a long style guide. But it is hard and unnecessary to modify the code style of a large project with another set of self-consistent styles. - Code design:
broad-except
,protected-access
. These, probably, should not be disabled. However, better solutions might just require large scale refactorization, which is undesirable.
Messages not to be disabled
Up until now, one item is found to be important and should not be disabled: cell-var-from-loop
.
Consider this case, where i
turns out to be the same in all three lambda functions.
This is where the cell-var-from-loop message will be raised. The correct way is to define the lambda function with a default argument,
More to be updated in the future.
References: