Skip to content

Do you use an python code analyzer?

I’ve got a question out there for everyone doing Python hacking - does your normal coding cycle include an analysis tool ala Pylint/PyChecker/PyFlakes?

Do you just rely on intelligence in your IDE of choise (Wing, Komodo, Eclipse+PyDev)?

Do you feel the need for the analyzers, or do you “discard” them in favor of writing unit tests/doctests first (personally I don’t find the two exclude one another) to verify functionality over “correctness”.

Which (if any) do you prefer? Do you setup automatic check-in triggers?

Or, do you really take the conformity-to-style-and-rules-correctness to a higher level and auto-pipe checked in code through a PythonTidy?

  • At Resolver we do TDD. We also have a PyLint step in our build that will fail if PyLint reports certain errors.

    The errors we are particularly interested in are:

    Unused imports
    Unused variables
    Missing (i.e. misspelt) variables
    Shadowing built-ins
    Redefining methods/functions

    Some of these our tests would normally catch anyway - but unused imports and variables is particularly useful.
  • Matt
    I'm trying to get better about using PyLint as a regular check on my code. I've heard of PyChecker and PyFlakes, but I got the impression those were more for actually incorrect code rather than stylistic issues, and my code coverage in unit tests is pretty good so I have less of a need for them.

    (As a note, Brandon Corfman has a plugin to integrate PyLint with Komodo, which is how I use it.)
  • Dan
    pylint, all the way. It's caught quite a few subtle bugs that might not have been picked up during testing. Things like noticing when a function can return different variable types, or you're inadvertently overwriting global or builtin variables. And it plays nicely with vim, so it takes almost no time to check code.

    I usually turn off a lot of the more anal checks of formatting style, though, especially when I'm dealing with other people's code
  • Pete
    I love me some pychecker and pyflakes. I really wish something simple and static like pyflakes could get rolled into the Python standard libraries. I'm sad to see it has fallen out of development recently.

    These tools are not part of my "day to day", but running them over my codebase once in awhile always finds errant corner cases.

    9 times out of 10 the problems these find are in my error handling code.
  • Brandon Corfman
    Yes, pylint -e (reporting errors only) is part of my coding cycle, whenever I've made a bunch of significant additions or changes to my code. It helps weed out many of my initial runtime errors. I've got it plugged into my Komodo toolbox.
  • Some of these tools (e.g. pychecker) get really confused by Zope 3 stuff, so I can't use them. I've a self-written script that checks for unused imports. I rely on unit tests to catch syntax errors. And yes, there's a buildbot instance that runs all tests on every checkin, then produces nightly test suite code coverage reports plus the above-mentioned unused import checker reports.
  • I use PyFlakes from TextMate for a few reasons:
    - It helps me to clean up the imports (remove unused imports)
    - it helps find spelling mistakes and syntax errors quickly

    I do write unit tests but I don't have tests for everything and PyFlakes is just another tool to help me write good code.
  • I use PyFlakes from TextMate for a few reasons:
    - It helps me to clean up the imports (remove unused imports)
    - it helps find spelling mistakes and syntax errors quickly

    I do write unit tests but I don't have tests for everything and PyFlakes is just another tool to help me write good code.
  • Jeff McNeil
    We've actually got it tied into our buildbot system. Every commit is going to trigger a build which runs PyChecker, our unit test suites, and finally a Figleaf coverage scan. If code coverage drops below 90%, we fail that step.

    I find that it's most helpful in catching problems with quick updates, such as those done with vim Friday afternoon at 4:30.
  • Jeff
    komodo and unit tests during initial design and development, pylint and scite during refactoring
  • Ed Page
    I recently created a Makefile that will find all python scripts and make a pyc (basic syntax check), doctest, pychecker, pep8, and give warnings for @todo's and errors for @bug. Once I have full unit tests setup I'll add that to it also.

    I'd like to use something like scons instead of Make but the next gen build systems seem odd for these custom jobs.
  • That's fantastic combination of ideas, and having them all automated is nice.
  • Never use them. =) Although I might if pychecker or something ever got integrated into the stdlib. But I don't see that happening any time soon since I don't think any of the tools use the AST directly yet.
  • Jay
    pylint + flymakes (Emacs). It runs pylint as you type and highlights errors and warnings. Cuts down significantly on save/run cycles to catch syntax errors. I don't know how I lived without it.

    My only complaint would be sometimes it highlights things I don't care about but I haven't figured out the pylintrc configuration completely. But that's just my own fault. As long as you set your indention the false negatives aren't too bad.
  • Paul Hildebrandt
    We require developers to pylint their code on our project. I tried pycheck and pylint and liked pylint better. I like PEP8.py but I don't think I could get the guys here to use it. I do use Eclipse+PyDev (the commercial version, well worth the money). I still run pylint alongside it's checkers. I want to starting running figleaf to check out coverage on our unittest but I just haven't started that yet.
  • Zachary Voase
    I actually enforce my own good coding standards in my code at write-time. Apart from that, pylint is very useful at finding certain semantic errors and ensuring that my code conforms to some very strict standards.
blog comments powered by Disqus