ALLFED-Repository-Template

**If this is the first time you want to use this template, please go through the Github training first. This will give you the neccesary background knowledge to understand what is happening here.

How to use this template

Use this as template when you start a new project by clicking "Use this template" in the top right.

Then follow all the descriptions below.

ALLFED Python Style Guide

All code written for ALLFED should follow the PEP 8 Style Guide for Python. Especially important are:

Keep the code well documented
Every function needs a docstring in this form:

def count_line(f, line):
    """
    Counts the number of times a line occurs. Case-sensitive.

    Arguments:
        f (file): the file to scan
        line (str): the line to count

    Returns:
        int: the number of times the line occurs.
    """

Write decoupled code, e.g. Functions should do exactly one thing and be as short as possible
Naming conventions:
- Snake case for variables and module: variable_name, my_module.py
- Camel case for class name: MyClass
- Camel case with spaces for jupyter notebook: Analyze Brain Data.ipynb
Delete dead code! Don't outcomment code you don't use anymore, but delete it instead. If you need to find it again, that's what we have git for.
Use Jupyter Notebooks only for explanations and visualization. The actual programming should be happening in .py files.
This repository is automatically set up with Github Actions/Lint Action that will format your code using black and check for problems with flake8 (without E203, W503). If either of them fails, you will not be able to merge your files unless you fix it. If this creates problem you cannot solve contact: florian@allfed.info
You can deactivate the branch protection that makes sure that only correct and styled code can be merged, but it is not recommended.

To make this easier you can use linter (auto-formatter) that change your code to be formatted in PEP 8 when you safe it. E.g. here for Spyder or VS Code.

Testing

We want to create reliable code. This means, as much of the code needs to be automatically tested, to make sure that everything runs as intended. Therefore, every possible function should have some kind of assert that tests if it works. We use pytest pytest as our main test suit. All tests that you put in the tests folder in here are automatically run every time you push code. You can read more about testing here. To adapt the testing.yml to your repository you just have to adapt the requirements in requirements.txt. Everything else should work on its own. You can find an example of how a test file should look like in the tests folder. Once you go the testing set up, also make sure to add the testing badge to the readme of your repository. Simply change the URL to your repository in this badge:

Documenting in small projects

Documenting your code is only one part of the documentation we want to create. Every larger repository needs:

a readme file that explains what the repository is for and how it is organized, which should contain:
- A one-sentence description of your project
- A longer description of your project
- Installation instructions
- General orientation to the codebase and usage instructions
- Links to papers
- Links to extended docs
- License
a tutorial Jupyter Notebook to explain how the repository is supposed to be used

Documenting in big projects

All the things for the small projects, but also:

An automated documentation via Gitub Actions. This is already set up in this repository. Is uses the code from this post and combines it with this one. It also is setup that it will only look for python files in the src folder. So, make sure that everything is in there (you can changes this behavior in the main function of automate_mkdocs.py). To get it running do the following
- Change the names in mkgendocs.yml and mkdocs.yml so they fit your repository
- go to Settings --> Pages
- select deploy from a branch as source
- select gh-pages as branch at root (for this option to pop up the docs.yml file has to have run succesfully at least once, this should happen when you push anything in your repository)
- The end result will look something like this
- The automated documentation part is still a bit wip, if you run into problems contact florian@allfed.info
Create a visual representation of how the different files interact with each other

Issues

Every time you come across a problem that you do not plan to fix in the next day, please open an issue in the repository to make sure that it does not get lost. This also allows you to assign tasks to other coders on the team. For a short intro to issues, see here.

Making the repository citable

All ALLFED repositories should be citable by release. For this we use Zenodo. This has to be activated by an Admin (so either Florian or Morgan). Once you have a manuscript where you need to cite the repository let them know and they will activate it. This will also create a doi badge, which should be included in the readme, like this:

ALLFED Plotting Style

All plots created for ALLFED should look and feel the same. You can activate the ALLFED style by simply starting your code with:

plt.style.use("https://raw.githubusercontent.com/allfed/ALLFED-matplotlib-style-sheet/main/ALLFED.mplstyle")

If you need to create your plots in ALLFED style, while being offline just download the file and change the path to local.

Project Skeleton

This repository already has the folder structure we use for repositories. Every folder has an additional readme, to tell you what needs to go in there.

Making the repository a pip installable Python package

For some repositories it makes sense to make them installable via pip (e.g. a model we want to share easily). In this case you can use the explanation here. This repository already contains a setup.py that can be used for that. If you want to install it to your local environment just run pip install -e . while being in the folder that contains setup.py.

Environment

Every ALLFED project is run in its own virtual environment. Therefore, every project needs an environment.yml file. The one in this repository is only an example and should not be used for any actual project. To create and organize virtual environments we use conda.

Requirements

Every ALLFED project needs a requirements file that specifies what packages are needed to run the project. You can find an example file in the repository. If you use a lot of packages you can use pipreqg to find them all.

License

ALLFED publishes its code in Open Access. For this we use the Apache 2.0 License. This license allows very free use of the code, but makes sure that ALLFED cannot be sued if something goes wrong with the code. The license template in this repository needs to be adapted when a new project is created. You can include the following license badge in your readme:

Gitignore

The .gitignore file is the default one for Python. Make sure you change it when using another programming language.

Acknowledgment

This is strongly based on the "Good Research Code Handbook". If something here confuses you, it makes sense to read about it there. Pretty good explanations.

zarishabbas/Github-Training-Repository