Docstrings for all methods and class

[cosminmarina]

The class CRO_SL is the only class/method with a respectable docstring. Having proper docstrings can help to auto-generate with Sphinx the Documentation of the pkgs in order to make it available. And this will help other people to contribute to pkgs if some bus/issue found, or if they propose some kind of enhancement.

I propose to add the corresponding docstrings following the PEP 257 convention. Specifically, I propose the following structure:

"""
name_of_class_or_method

Description of class or method functionality, and main notes or caveats about it.

Parameters
----------
name_param1: type(s)
    Description of parameter details.
name_param2: type(s)
    Description of parameter details.

Returns
---------
name_of_return[optional]: type(s)
    Description of return details.
"""

In order to make more easy the documentation and the tracking of this issue, I provide a list of .py files where the docstrings needs to be added as a task list. When a commit in a specific branch for documentation finish the docstrings of a file, it can be marked as completed:

• AbsObjectiveFunc.py
• CRO_SL.py
• CoralPopulation.py
• Substrate.py
• SubstrateInt.py
• SubstrateReal.py
• TestFunctions.py
• operators.py

Also, if any of you disagree with the propose issue, or with the task list, comments and suggestions are welcome.

[eugenioLR]

I've created a branch to write the documentation in. The changes specific to this issue should go into that branch