Coding Standards

Start with Python Style Guide

No tabs in code, period. Spaces only.

No code past column 79.

No trailing whitespace. (I recommend enabling a Git hook for this.)

Continuation lines should be indented two spaces (half of a full four-space indent) past the continued line.

Prefer “double-quotes” to ‘single-quotes’. (It’s easier to grep through the code if you don’t have to check for both kinds of quotes.)

• Class names: CapWords
• Constants: UPPERCASE_WITH_UNDERSCORES
• Others: lower_case_with_underscores
• Private: _leading_underscore

Don’t use “from something import *” (“from something import a, b, c” is fine — it’s only the “*” that leads to confusion.)

Write unit tests for everything that could possibly break. The GUI layer is hard to test, so keep it thin.

Avoid unnecessary coupling:

• Follow the Law of Demeter. Objects should only talk to immediately contained objects, objects passed in as parameters, and to objects they create.

Initialize instances as thoroughly as possible in __init__, rather than tweaking them after creation.

Raw data should go in separate Python modules with “data” in their names. Keep live code out of these modules; they should be easily editable by non-programmers. (Simplified Python is cleaner than XML, and avoids needing libraries or custom parsers.)

Keep in mind that everything is event-driven. Do not use blocking I/O, or write blocking functions that take more than 0.01 seconds to execute.