######################
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