-
Notifications
You must be signed in to change notification settings - Fork 58
/
CODING_STYLE
52 lines (36 loc) · 1.97 KB
/
CODING_STYLE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
This codebase conforms to a single, consistent coding style which is
outlined in the following text. New submissions will be rejected if they
do not conform to this style.
The most important rules are the following:
All code must conform to the Fortran 95 standard (ISO/IEC 1539-1: 1997).
Fortran 2003 is allowed for all features which have wide compiler support,
as outlined in the table found at the following URL:
http://fortranwiki.org/fortran/show/Fortran+2003+status
In particular, Cray, gfortran, IBM, Intel and PGI compilers must all have full
support for the language feature. At present, this excludes the following
Fortran 2003 extensions:
- Parameterized derived types
- Support for international character sets
- Derived type I/O
All Fortran keywords and intrinsics are uppercase, user-defined
function, subroutine and variable names are lowercase.
- One exception to this rule is the MPI libraries. For this, both constants
and routine names are uppercase.
All function and subroutine blocks are separated by three blank lines.
Within the rest of the code body there should never be more than one
consecutive blank line.
Indentation is two spaces. Continuation lines are indented by four spaces.
Comments should follow the same indentation as code.
All code lines must be 80 columns or less. This includes comments.
A comma is always followed by a space with the exception of array indexing.
The equals sign in assignments is always surrounded by whitespace.
Lines must not contain trailing whitespace.
Lines must not contain tab characters.
Use 'END IF' and 'END DO' instead of 'ENDIF' and 'ENDDO'.
Use F90-style binary operators instead of F77 ones. eg. use '=='
instead of '.EQ.'.
Variable names must not clash with Fortran keywords.
If a line is split on an operator, the operator should appear at the
beginning of the continuation line rather than at the end of the split line.
For all other matters of coding style, try to match the style used throughout
the rest of the code.