Thanks for contributing to our code!💜 Here's a couple of guidelines that you should keep in mind.
To setup your Unix environment, run:
cd dev_scripts && ./setup_dev_environment.sh
Read through the script first to see what it does (it's not long, I promise). It is useful especially if you use VIM as your text editor, as it sets it up to use our code style rules. If you use a different editor, we welcome if you contribute your config files!
The script also tries to install the configargparse
Python dependency,
which is needed for the code autoformatting (see below).
- Some ABIN functionality requires external libraries; see README.md for details.
- To build and run Unit Tests, you will need to install pFUnit library, you can use
dev_scripts/install_pfunit.sh
.
Here's a quick summary of our code style that we try to adhere to:
- use
implicit none
everywhere, no exceptions! - each function/subroutine argument should have the intent attribute.
- use
REAL(DP)
for real numbers, theDP
constant indicating the kind (precision) is defined inmodules.F90
- variables and subroutines in modules should be private by default, use
private
attribute,e.g.
module mod_my_module
private
integer :: public_var
integer :: private_var
public :: public_var
public :: public_subroutine
contains
subroutine public_subroutine
...
end subroutine public_subroutine
end module mod_my_module
We're using fprettify
to automatically format our code; you should use it too!
That way you don't need to worry about it and just apply the autoformatter at the end, like so:
./autoformat.py
This will autoformat all Fortran files in src/
. You can also autoformat individual files:
./autoformat.py source.f90
Here's a quick summary of our formatting style, as it is defined in .fprettify.rc
config file.
- maximum line-length should be 100 characters.
- use 3 spaces for indentation, no tabs.
- use capital letters only for defined constants (e.g. those from module
mod_const
). We use lower case for everything else. - use
snake_case
for naming your subroutines and variables. (notcamelCase
) - use C-style relational operators (
< > == /=
) instead of the old FORTRAN style (.gt. .lt.
) - comments should start at the same indentation level as the code they are commenting.
- use an exclamation mark to start a comment
To ignore bulk whitespace changes in git blame history, use:
git blame --ignore-revs-file .git-blame-ignore-revs
or to do it automatically:
git config blame.ignoreRevsFile .git-blame-ignore-revs
Last but not least, to get your code merged to the main repository, please open a Pull Request (PR) on Github. If you're not familiar with Pull Requests, take a look here.
It's super easy, barely an inconvenience! (assuming basic familiarity with Git)