The following guidelines describe some coding recommendations to write Fortran source files.

Notus developers strive to keep an homogeneous and coherent source code. The Fortran 90 free form is used as a baseline. Please consider the additional rules that follows when coding.

General style.

1. Use lowercase characters.

   Lowercase character are more readable than uppercase.

2. Avoid long lines.

   Fortran 90's free form does not accept lines longer than 132 characters. Splitting long lines often increases readability.

3. Comment your code.

   Code comments are good practice, but its better to avoid the need for comments!

   Think twice before comment: do not paraphrase yourself, reduce or delete the need for comment by using self-explanatory names.

   Use doxygen.

4. Write one routine per file as much as possible.

   Its easier to find routines this way.

5. Use english exclusively.

6. Use Emacs indentation.

   The shell script formatCode.sh automatically indents the code.

7. Use alphabetical order by default.

   It's easier to find in such lists.

Naming conventions.

1. Use self explanatory variable names.

   Thus every one knows what is your variable every time he sees it in the source code.

2. Use as little as possible abbreviations.

   An abbreviation may not be clear for every one, so try not to use them. Although, very long variable names is sometimes not quite readable either, then abbreviations becomes a better alternative.

   For this situation, a list of common abbreviations has been written below; have a look before creating your own. If you really need new ones, try to reduce their number to a minimum.

List of common abbreviations

• coef for coefficient.
• dir for direction.
• ib for immersed boundary.
• ibc for immersed boundary condition.
• isd for immersed subdomain.
• _u, _v, _w suffixes for fields discretized at the \(x\)-, \(y\)-, \(z\)-faces, respectively.
• is_ prefix for variables of type logical.
• _n suffix for variables at the current time step \(t_n.\)
• _mn1 suffix for variables at the last time step \(t_{n-1}.\)

1. Names of modules defining global scalar variables start with variable_.
2. Names of modules defining global field array variables start with field_.

Module prefixes:

• variables_ for modules defining global variables.

1. Names of modules defining subroutines start with mod_.

• type_ for modules defining new derived types.
• mod_ for modules defining subroutines.

Unclear rules

1. One routine, one goal (short routines).

2. Write one routine per file.

   Its easier to find routines this way.