= Procyon coding standard =

Procyon adheres closely to [http://divmod.org/trac/wiki/CodingStandard the Divmod coding standard]
(which in turn builds on the Twisted coding standard.)  There are however some deviations:

  * One (1) line between methods and closely related code (`registerAdapter` or `registerUpgrader`
  after a class definition, for example.)
  * Two (2) lines between classes, import statements and generally code that has little or no relation
  to the proceeding code.

To reiterate some key points from the aforementioned coding standards:

  * Lines are flowed at 79 columns, more or less.  Don't sacrifice readability for newlines, use common
  sense.
  * Doc-strings are extremely important and need to follow some guidelines:
    * Doc-strings should be clear in the information they are attempting to convey, but not overly verbose,
    properly punctuated and written in plain English.
    * Use [http://epydoc.sourceforge.net/epytext.html Epytext markup] to properly document attributes,
    parameters, exceptions and so forth.  
    * The first line of the doc-string should be a brief (not passing the 79 column mark, if at all possible)
    description of the thing it is describing.  Optionally, next paragraph should then go into more detail
    and finally followed by parameters (type, then parameter) then exceptions (if any) and finally the return
    type (if any.)
    * Use a doc-string (following the above rules) for modules when the behaviour is well-contained, not entirely
    obvious and there is a need for an example. (See [source:trunk/procyon/api/tvdb.py] for an example.)
  * Comment any quirky or unclear behaviour with a concise comment.

In general, the existing codebase should be used as a guide on how to layout a particular piece of code.

Do '''not''' submit (or commit) patches for largely undocumented code... ever.