Style Guide
Unless otherwise noted, this code should conform to PEP 8
(http://www.python.org/dev/peps/pep-0008)
PEP8 Exceptions
- Indentation: 2 spaces
- Unicode: unicode may only be included in test cases, docstrings, and
comments. Elsewhere \u escapes should be used.
Files should be encoded as ASCII or utf-8.
- Tabs: never use.
- Docstrings: Not needed on signal handlers, one-liners, or magic methods
(methods of the form __foo__).
- Line length: 80 chars is ok.
- Blank lines: should contain no spaces or tabs
Between short methods, no blank lines is ok
- Comments: A comment at the start of an indented block should come after that
block’s docstring, if any. This helps with folding.
- Method ordering: ???
- Imports: never use from foo import * except in test_foo.py .
Always use it in that case.
Naming Conventions
- Widgets
- written in CamelCase, even when they are an instance variable.
- Math variable names
- Follow the convention from linear algebra. A capital single letter (eg Z)
denotes an array. A lower case single letter (eg k) denotes a scalar.
This is an exception to the typical rule that instance variables and
locals should be in lowercase.
- The following single letter names are reserved project wide:
- q: The Q (quality) of a filter
- z or Z: One or an array of zeros of a system
- p or P: One or an array of poles of a system
- k: the k factor in a system’s ZPk representation. NOT the same as
gain!!!
- h: the passband gain of a system
- w0: the critical frequency of a system
- Component names
- In keeping with the electrical engineering convention, reference
designators should always be in upper case.