Practical Pylint usage
Unfortunately due to the nature of the Python language its easy to create code that's syntactically valid but will fail at run time. There's a very large number of ways that this is possible and if you are attempting to do sound engineering on your project you will want to minimize these issues as much as possible. Pylint is a great tool for finding errors in Python code, it does this by running a static analysis on the source code and produces a report for potential problems.
The issue with Pylint is that it can report a lot of stuff and the most important issues can get lost in a sea of data. Pylint has 3 levels of output:
- Errors: anything that's guaranteed to be a problem
- Warnings: likely to be problematic but can't definitively be labelled an error since there's rare situations in which the code could be valid
- Conventions/refactor: code smells and other potential areas of improvements
It's very obvious that you need to deal with errors and warnings but the conventions are something that's not so definitive. On top of this the amount of output from the conventions categories can dwarf the Error and Warnings outputs. Pylint does however have some options for running in different ways. There's an Error's only mode that will only report errors, this is very useful as a part of CI pipelines. You can invoke Pylint in Error-only mode by using:
pylint -E
Another very useful way to use Pylint is to just look at Errors and Warnings, to do this you need to disable the conventions and refactors messages. You can do this like so:
pylint --disable=R,C
This I find especially useful when I am new to a project, since it gives a quick report of anything potentially broken without having to get bogged down with too much information.