Style Guide

Unless otherwise noted, this code should conform to PEP 8 (

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 . Always use it in that case.

Naming Conventions

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.


Follow all recommendations at