You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Basic concepts:

  • Use PyLint as the verification tool for code style

  • Start with base rules, and add additional ones every time we run into any ambiguous scenarios

  • Aspire to only support rules which can be verified automatically

  • Upon PyLint new release, consider the new base rules and possibly add new exceptions rather than changing the code to fit the new base rules

List of pylint builtin messages (rules): http://pylint-messages.wikidot.com/all-messages

List of additional rules:

  1. Line width should be capped at 100 rather than the default 79

  2. Exceptions

    1. Exceptions are a means of breaking out of the normal flow of control of a code block to handle errors or other exceptional conditions.

    2. Never use catch-all except: statements, or catch Exception or StandardError, unless you are re-raising the exception or in the outermost block in your thread (and printing an error message). Python is very tolerant in this regard and except: will really catch everything including misspelled names, sys.exit() calls, Ctrl+C interrupts, unittest failures and all kinds of other exceptions that you simply don't want to catch.

  3. Power Features

    1. It's very tempting to use these "cool" features when they're not absolutely necessary. It's harder to read, understand, and debug code that's using unusual features underneath. It doesn't seem that way at first (to the original author), but when revisiting the code, it tends to be more difficult than code that is longer but is straightforward.

  4. Classes

    1. If a class inherits from no other base classes, explicitly inherit from object. This also applies to nested classes.

  5. Imports

    1. Import modules and (and not attributes).

    2. Use relative import when possible (while maintaining readability).

    3. When importing several modules from the same package use ‘,’ and ‘(‘, ‘)’. e.g.:

 From x import (a,

                                   b)

       6) Naming  

  • if the variable is private/protected, use ‘_’ as a prefix to the variables name.

  • single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g. class_

7) between class declaration and any following member should be at least one empty line.

8) When creating a mixin class, the name should end with ‘mixin’ (not case sensitive) - this will enable ignoring missing members.

TODO: attach an updated PyLint configuration file


  • No labels