Please read this carefully.
- We use the following style for naming variables and functions:
- variables are named lowercase with underscores (
_
) if necessary, e.g.:my_new_var
; - function names start lowercase without underscores and can be continued uppercase, e.g.:
myNewFunc()
; - modules always start with
m_
and are always lowercase without underscores, e.g.:m_mynewmodule
.
- variables are named lowercase with underscores (
- Remember, for fortran
THIS
andtHIs
andthis
are all the same. - Use indentations when entering loops, functions, conditional statements etc! Standard for this code is two spaces per one indent.
#ifdef
-s and other precompiler macros can also be indented(!), as nowMakefile
precompiles the code with the newcpp
compiler before compiling with fortran.- Please use spaces and brackets to make the code more readable:
- in arithmetic statements, e.g.:
2 + 3 * 5 / (2 + a)
instead of2+3*5/(2+a)
; - in function arguments, e.g.:
myFunction(2, var, "my string")
instead ofmyFunction(2,var,"my string")
; - in assignments, e.g.:
my_var = my_other_var
instead ofmy_var=my_other_var
; - in conditional statements, e.g.:
if ((one .eq. 1) .or. (two .eq. 2))
instead ofif(one.eq.1 .or. two.eq.2)
.
- in arithmetic statements, e.g.:
- Try to use standard Fortran
.eq.
,.lt.
and other logical comparison operators instead of==
,<
. - Use
interface
-s andmodule procedure
to overload some of the auxiliary functions and make them accept generic arguments. - Do not use
goto
statements.
All these advices and rules are simply to make the code look visually comprehensible and help those working with it enjoy the time. Thank you for following these advices.
Branching Policy
To prevent v2
from growing to become the Lovecraftian monster it once was we highly encourage both users and developers to follow the guidelines on branching policies.
- For development:
- all the new features shall be added to
dev/<feature>
branch; - as soon as the new features are tested they can be pushed to the main development branch:
dev/main
.
- all the new features shall be added to
- For users:
- user-specific branches are allowed (e.g. to test userfiles), but as soon as it works we highly encourage people to merge their new userfiles to
dev
; - the naming for user-specific branches shall be the following:
user/<problem>
oruser/<username>
; - if any of the core routines is modified, we highly encourage to use the
dev/...
branching instead of theuser/...
.
- user-specific branches are allowed (e.g. to test userfiles), but as soon as it works we highly encourage people to merge their new userfiles to
The dev/main
branch is the most up-to-date tested version of the code, and it will be merged to master
as soon as all the new features are documented.
Development
Since v2.4
code formatting policy is employed. To follow the proper formatting automatically we use the fprettify
tool. To install fprettify
in the local directory (via pip
) one can use the dev-requirements.txt
file, by running the following:
# create a local pip environment
python3 -m virtualenv venv
# activate it
source venv/bin/activate
# install required modules
pip install -r dev-requirements.txt
After that one can either use the tool in a stand-alone manner:
./venv/bin/fprettify -i 2 -w 4 --whitespace-assignment true --enable-decl --whitespace-decl true --whitespace-relational true --whitespace-logical true --whitespace-plusminus true --whitespace-multdiv true --whitespace-print true --whitespace-type true --whitespace-intrinsics true --enable-replacements -l 1000 [FILENAME.F90]
or in the VSCode environment (see the extension list in the .vscode/settings.json
of the current repo).