112 lines
2.4 KiB
ReStructuredText
112 lines
2.4 KiB
ReStructuredText
######################
|
|
Programming guidelines
|
|
######################
|
|
|
|
|
|
***************
|
|
Version control
|
|
***************
|
|
|
|
Version control is managed with `Git <http://git-scm.com/>`_.
|
|
Issue tracking and repository management are done using `GitLab <https://about.gitlab.com/>`_
|
|
at http://git.metabarcoding.org/.
|
|
|
|
|
|
Branching strategy
|
|
==================
|
|
|
|
|
|
Master branch
|
|
-------------
|
|
|
|
The master branch should only contain functional scripts.
|
|
|
|
|
|
Topic branches
|
|
--------------
|
|
|
|
Topic branches should correspond to development branches revolving around a topic corresponding
|
|
to the branch's name.
|
|
|
|
|
|
Release branches
|
|
----------------
|
|
|
|
Release branches should start with duplicates of tags and be used to patch them.
|
|
|
|
|
|
Tags
|
|
----
|
|
|
|
Tags should never be committed to.
|
|
|
|
|
|
Rebasing
|
|
--------
|
|
|
|
Rebasing should be avoided on the distant server.
|
|
|
|
|
|
Merging
|
|
-------
|
|
|
|
Merging should never overwrite on a release branch or on a tag.
|
|
|
|
|
|
Branching strategy diagram
|
|
--------------------------
|
|
|
|
.. image:: ./images/version_control.png
|
|
|
|
|
|
Issue tracking
|
|
==============
|
|
|
|
Issue tracking is done using `GitLab <https://about.gitlab.com/>`_ at http://git.metabarcoding.org/.
|
|
Creating a branch should always lead to the creation of a label that refers to it in GitLab.
|
|
Tickets should always be labelled with the branches for which they are relevant.
|
|
|
|
|
|
**************
|
|
OBITools3 wiki
|
|
**************
|
|
|
|
The OBITools3 wiki is managed with GitLab.
|
|
|
|
|
|
*********************
|
|
Programming languages
|
|
*********************
|
|
|
|
C99 :
|
|
* All the low-level input/output functions (e.g. all the `ObiDMS <formats.html#the-obitools3-data-management-system-obidms>`_ functions)
|
|
* Computing-intensive code (e.g. alignment or pattern matching)
|
|
|
|
`Cython <cython.org>`_ :
|
|
* Object layer
|
|
* OBITools3 library
|
|
|
|
`Python 3 <https://www.python.org/>`_ :
|
|
* Top layer code (scripts)
|
|
|
|
For the documentation, `Sphinx <http://sphinx-doc.org/>`_ should be used for both the original
|
|
documentation and for the generation of documentation from the python code. `Doxygen <http://www.stack.nl/~dimitri/doxygen/>`_
|
|
should be used for the generation of documentation from the C code, which should be then integrated
|
|
in the Sphinx documentation using `Breathe <https://breathe.readthedocs.org/en/latest/>`_.
|
|
|
|
|
|
******************
|
|
Naming conventions
|
|
******************
|
|
|
|
.. todo::
|
|
Look for usual naming conventions
|
|
|
|
|
|
*****************
|
|
Programming rules
|
|
*****************
|
|
|
|
* The *int* type should never be used
|
|
|