The great thing I found about a code validator is that it points out the mistakes or things that are wrong or unnecessary in your code that you might have missed yourself. When a file gets above 250 lines for me, I have to admit I start to forget some of the things I might have written at the beginning. Pylint finds, for example, variables that are created or even assigned values, but never used. It also pointed out to me that it is dangerous to put a default arguments for a list in a method signature, e.g. def my_method(self, my_val=[]). (In this case, apparently it's better to be something like my_val=None.) I found I also have a nasty habit of making "wild imports" of the contents of modules when I'm tired, i.e. a statement like from my_module import *, which is bad! It's better to be specific, like from my_module import a, b, c.
The first thing with Pylint that I did was follow the easy tutorial on the official site. This gives you some common things to try out on the command line. I found this was much easier (especially when you're first learning) to run on the CLI, rather than using Pylint integrated with Eclipse and Pydev, which is my usual IDE of choice. You just run Pylint on a Python file and view the output, which typically is a long ASCII report with more information than you'll really care about. It does however, give you a sometimes funny comment on the quality of your code. My first result for this was:
Global evaluation ----------------- Your code has been rated at -2.5/10
Great eh? :-D Encouraging for the first time validation of any of my Python scripts! After fixing five of the things it warned me about, I did get that rating back to 10/10.
Anyway, after playing around I found it was helpful to run files on the CLI with these two options:
pylint --reports=n --include-ids=y my_file.py
Then of course, I found there is a .pylintrc config file you can set in your home directory to contain the most common options you want Pylint to use by default every time you run it (so you won't have to put token options in your pylint command statement).So, of course you create a .pylintrc config file in your home directory (or other location). You can copy the example .pylintrc in the Pylint source code examples directory and paste it, or run an rc file generation command (which I didn't do - so call me a geek, I'm starting to love reading the source of OSS programs).
vim ~/.pylintrc
In the REPORTS section, I altered these:
output-format=colorized
include-ids=yes
reports=no
The next time I ran Pylint on a file, it found the configuration file for my user and deployed using the options set in there. But then I also realised, sometimes I will want to run Pylint on all the Python files in a package or directory, not just one. So, I need a second .pylintrc file for these options because I want it to write text files containing the Pylint checking output.
cp ~/.pylintrc ~/.pylintrc2
vim ~/.pylintrc2
I went to the REPORTS section again, and altered these options:
files-output=yesoutput-format=text
When running Pylint again, I needed it to point to the second .pylintrc file instead of the default, and I received text output files (one for each Python file) containing lots of lovely warning messages. I ran Pylint it on all the Python scripts in a directory (and its subdirectories!):
pylint --rcfile=~/.pylintrc2 my_python_dir
Well, now I've been using Pylint for a week, I can't imagine ever not using it! It's so helpful and invaluable at finding the bad things I miss myself. I guess it does have its downside, which is sometimes providing an overload of warnings about issues that won't actually stop a program running. It also can't find some things that are imported, e.g. functions from a wildcard import statement. However, it's fast and reliable and follows PEP8 recommendations. Merci beaucoup, Logilab Pylint people!
Thanks, its really helpful.
ReplyDelete