Please read this carefully.

  1. 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.

  2. Remember, for fortran THIS and tHIs and this are all the same.
  3. Use indentations when entering loops, functions, conditional statements etc! Standard for this code is two spaces per one indent.
  4. #ifdef-s and other precompiler macros can also be indented(!), as now Makefile precompiles the code with the new cpp compiler before compiling with fortran.
  5. Please use spaces and brackets to make the code more readable:
    • in arithmetic statements, e.g.:

      2 + 3 * 5 / (2 + a) instead of 2+3*5/(2+a);

    • in function arguments, e.g.:

      myFunction(2, var, "my string") instead of myFunction(2,var,"my string");

    • in assignments, e.g.:

      my_var = my_other_var instead of my_var=my_other_var;

    • in conditional statements, e.g.:

      if ((one .eq. 1) .or. (two .eq. 2)) instead of if(one.eq.1 .or. two.eq.2).

  6. Try to use standard Fortran .eq., .lt. and other logical comparison operators instead of ==, <.
  7. Use interface-s and module procedure to overload some of the auxiliary functions and make them accept generic arguments.
  8. 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.
  • 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> or user/<username>;
    • if any of the core routines is modified, we highly encourage to use the dev/... branching instead of the user/....

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).