mudpy

These rules attempt to embody a rudimentary style guide for mudpy source code and embedded documentation. Submitted patches should be in unified diff format and, where possible, attempt to conform to this guide.

• when bracketed code is expanded into multiple lines, its terminating bracket is indented the same amount as the line on which its corresponding initial bracket appears (essentially K&R style)
• if bracketed parameters are too lengthy/numerous to fit together on one line, all are split onto individual lines
• all indentation uses 3-space tab stops
• no line of code (including indentation) exceeds 79 columns
• line continuations are best avoided, relying on bracket expansion where possible; when continuations are absolutely necessary, subsequent continued lines are indented one level past the initial line
• every function, method, class or similar structure has a descriptive docstring
• when markup is used in embedded documentation (docstrings, comment blocks, et cetera) it conforms to the reStuctured Text specification
• any module required by code in a function or method is imported immediately following the docstring; import x from y constructs are avoided whenever possible
• characters outside the ASCII printable set (decimal byte values 32 through 126 and line termination appropriate to the developer’s platform) are avoided where possible; if necessary, extended characters use UTF-8 encoding and are accompanied by a correct coding directive at the beginning of the file
• any text constants in code are declared as unicode; when actual byte data is required instead, its entry point is documented clearly in preparation for an eventual Python 3 transition
• all text handling routines operate on unicode data, normalized as early as possible to eliminate compositing sequences