Jeremy Hylton : weblog : 2003-10-02

What real errors does pychecker catch?

Thursday, October 02, 2003, 12:13 a.m.

PyChecker is an invaluable tool, but its warns about too many things that are only sometimes a problem. I have found many bugs in Zope code using pychecker, but it takes extra effort to filter out all the false positives.

We have integrated PyChecker with the Zope test runner. If you run the tests with the -c argument, PyChecker is loaded and reports warnings, too.

I ran the ZODB3 test suite today with PyChecker enabled. It found several problems. Only one of the problems was very serious, but even the minor ones makes the code harder to read. I decide to keep track of which warnings were most helpful and which were most often spurious.

The three most helpful warnings were:

Unused local variables is a good warning, because they almost always mean there is code you can delete! Zope has a lot of local variables created for dubious optimization purposes. One side-effect is that useless local variables live on as the code changes.

Two warnings were all false positives so far as I could tell. There were a lot of warnings, and I only looked at a few before giving up.

No class attribute found. This happens a lot when you program with mixin classes and the mixin calls methods defined in the concrete class. The class itself doesn't define the method, but the classes that are actually instantiated do.

Parameter not used. If you multiple implementations of an interface, it is not always the case that all the arguments are used. As one example, there is a ZEO class that implements a getattr hook that always raises an exception. pychecker complains that the attribute argument is not used. This implementation of __getattr__() does not need the argument, but other implementations probably do. There are many examples in ZODB where there is a minimal implementation on an interface that ignore some arguments.