Module coding_style

The coding style for the Schlachtfeld project. A short overview of the functions and classes in a file should the first line of its docstring,

It should be tested with epydoc version 3.0 or higher.

Files which contain at least one class should be structured around imports, constants, classes, functions and self-test. Please look into the coding_style.py file to see an example and descriptions of each part of the file.

The files should rather contain too many comments than too few.

This coding style is in RFC mode: Request for comment. Please see it as a beta at best and type comments directly into this file, beginning with a "> " sign.

Useage: In the explanation texts the file should contain general usage instructions like ways to call the class and examples.

To get the coding style, have a look at the codefile, or let it be processed by epydoc.

Variables and comments should be in english. Classes should be written with leading Capital.

Functions in all lowercase, words seperated by underscores.

Plans and Ideas: Also the first docstring of a file should contain plans and ideas, so that they are all gathered at one central place and can be read out by epydoc.

This also eases the transition between version management systems (in future) and since epydoc produces nicely laid out websites, it still stays accessible.

Plans should be included once they are somewhat fixed, ideas should contain a link to a discussion page.

Once an idea got discussed, its solution should be included as a plan.

IDEA: Maybe plans and ideas could be put into functions which serve only as anchors for docstrings. Maybe they would justify adding a first section in sourcefiles namesn PLANS AND IDEAS. Epydoc will show them as functions, then.

To differenciate plans and ideas from other functions, they could all start with a common char, for example x like in:

x_plan_morale_implementation