CMItemplate developer guide¶
Here are a few simple guidelines to please be obeyed when working on CMIdiffract
Document your code!
Use spinx-compatible docstrings to document all classs, methods, functions, etc.
Write code that is compatible with the latest stable Python 3.x version.
Make use of NumPy as much as possible.
Source code formatting¶
CMI Python projects use the 4-spaces standard for indentation of blocks.
Do not use tabs, always expand to spaces.
Try to not extend lines beyond 100 characters
Keep the utf-8 coding directive in the first line
Keep the Emacs local variables section at the end of all files, and try to stick to the directives (manually) when not using Emacs.
Version control (git) details¶
CMItemplate uses git as a version control system with a central repositories on github.
CMItemplate uses the git-flow branching model
the principal development branch is
develop
all new developments should be done on a
feature/
branch and, once ready, be branched intodevelop
Never touch the branch
master
– this is to be done by the maintainers.the
master
branch is only for releases. There should never be any development done onmaster
, nor any release preparations. The latter is done onrelease/
, then the release is put ontomaster
, and possibly necessary fixes are done onhotfix/
.
Do not repeatedly branch feature branches into
develop
instead mergedevelop
into yourfeature/
branch.General documentation work should always be made on
develop
(only)!commit such doc-only updates as separate commits!
one can then merge these doc-only commits into
feature/
branches
Never implement a change twice manually. Implement it on the most appropriate branch, then merge it into whatever branch you want to have it.
Descriptions of source code files¶
Here one would provide a short introduction into the different code files, their intended content, and their interplay.