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.