Coding style in Fortran code of Elmer
Posted: 18 Dec 2015, 16:33
People have asked about the coding style instructions for Elmer. This is a short summary of coding style conventions followed in Elmer development. The choices have evolved with time and can be argued. Ultimately it is a matter of taste. We have tried to honor the current code base so that this does not give rise to major code modifications.
Coding conventions
- use uppercase for all Fortran constructs (DO, SUBROUTINE, MODULE, ...)
- use lowercase or CamelCase for variablenames
- use long descriptive variable names. Exceptions to this rule are indexes and other variables which have a very local scope.
- use 2 spaces for indentation (*)
- declare INTENT(IN), INTENT(OUT) or INTENT(INOUT) for subroutine arguments where applicable
- use empty lines to improve readability of code
- use doxygen comments (*) for modules and subroutines
- put (L)GPL license header with author info, updated authors for each module
- use Info level conventions (**)
Applying style
- Style will not be enforced for existing code
- New code should rather try to follow the conventions
- Independent modules can be more relaxed in adapting to the conventions
- Automatic emacs tool for performing code polishing to be provided: trailing white spaces, indentation
(*) doxygen example
(**) Info levels of Elmer code,
CALL Info('SubroutineName',Message,Level=4)
3 = warning
4 = highest priority
5 = default priority
6 = lower priority
...
10 <= debug priority
32 largest known priority index
Coding conventions
- use uppercase for all Fortran constructs (DO, SUBROUTINE, MODULE, ...)
- use lowercase or CamelCase for variablenames
- use long descriptive variable names. Exceptions to this rule are indexes and other variables which have a very local scope.
- use 2 spaces for indentation (*)
- declare INTENT(IN), INTENT(OUT) or INTENT(INOUT) for subroutine arguments where applicable
- use empty lines to improve readability of code
- use doxygen comments (*) for modules and subroutines
- put (L)GPL license header with author info, updated authors for each module
- use Info level conventions (**)
Applying style
- Style will not be enforced for existing code
- New code should rather try to follow the conventions
- Independent modules can be more relaxed in adapting to the conventions
- Automatic emacs tool for performing code polishing to be provided: trailing white spaces, indentation
(*) doxygen example
Code: Select all
!-------------------------------------------------------------------------------
!> Explanation what the module does...
!> ...
!-------------------------------------------------------------------------------
MODULE ...
!-------------------------------------------------------------------------------
!> Explanation what the subroutine or function does...
!> ...
!> Following may optionally be added
!> \deprecated Remarks if this is obsolite !> \todo Remarks what could be done
!-------------------------------------------------------------------------------
SUBROUTINE ExampleRoutine( a, b )
!-------------------------------------------------------------------------------
IMPLICIT NONE
USE DefUtils
CALL Info('SubroutineName',Message,Level=4)
3 = warning
4 = highest priority
5 = default priority
6 = lower priority
...
10 <= debug priority
32 largest known priority index