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.
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.
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
.pyfiles. - 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). 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: [email protected]
- 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.
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 reasonable 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:
You don't have to test every possible function. Just make sure that those are tested where you are doing custom analysis.
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
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.ymlandmkdocs.ymlso 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.ymlfile 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 [email protected]
- Change the names in
- Create a visual representation of how the different files interact with each other
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.
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:
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.
For published maps we use the Winkel Tripel projection. You can use it by reprojecting the CRS of your data on geopandas to +proj=wintri. The function in the example below can be used to include a border on your map, and modify the ALLFED plotting style to make sense for a map plot.
# Add border to map, remove gridlines and ticks (after activating ALLFED style)
def plot_winkel_tripel_map(ax):
border_geojson = gpd.read_file('https://raw.githubusercontent.com/ALLFED/ALLFED-map-border/main/border.geojson')
border_geojson.plot(ax=ax, edgecolor='black', linewidth=0.1, facecolor='none')
ax.set_axis_off()
world = gpd.read_file(gpd.datasets.get_path('naturalearth_lowres')) # Example world dataset
world = world.to_crs('+proj=wintri') # Change projection to Winkel Tripel
ax = world.plot() # Plot the map
plot_winkel_tripel_map(ax) # Modify style and add border
plt.show()The result should look like this:
Important note: The Winkel Tripel projection is a compromise projection used purely for visuals. It is not equal-area, conformal, or equidistant. This means that the areas, angles, and distances are not preserved. We use this projection to make our maps as easy to read as possible, but if you need to do any calculations on the map, you need to use a different appropriate projection to get the correct results. To learn more about map projections with geopandas, see here.
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.
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.
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.
Please make sure to include version numbers in your environment.yml. Otherwise it will be really annoying to get it to run again in the future.
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.
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:
The .gitignore file is the default one for Python. Make sure you change it when using another programming language.
- Best Practices for Scientific Computing
- General course to get to know the Python skills needed to the work at ALLFED
- We are using Github Copilot to write faster and cleaner code. If you would also like to have a license contact [email protected]
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.