source: LMDZ6/trunk/libf/phylmd/ecrad/radiation/CONVENTIONS @ 5450

Last change on this file since 5450 was 4773, checked in by idelkadi, 13 months ago
  • Update of Ecrad in LMDZ The same organization of the Ecrad offline version is retained in order to facilitate the updating of Ecrad in LMDZ and the comparison between online and offline results. version 1.6.1 of Ecrad (https://github.com/lguez/ecrad.git)
  • Implementation of the double call of Ecrad in LMDZ


File size: 2.9 KB
RevLine 
[4773]1The Fortran conventions that the author of the code in this directory
2aspired to are as follows:
3
4 - Module names are prefixed by the static library name, in this case
5   "radiation" (no need to suffix by "_mod" since this is always
6   obvious from the context).
7
8 - Names of derived types are suffixed by "_type".
9
10 - Implicit none everywhere.
11
12 - Logicals are prefixed by "do_", "use_" or "is_", and should have
13   clear descriptive names.
14
15 - All variables in SI units by default.
16
17 - Variables not in SI units have the units in the variable name,
18   e.g. pressure_hPa.
19
20 - Integers either prefixed by "j" to indicate loop counter, "n" to
21   indicate the size of an array dimension, or "i" otherwise.
22
23 - Loop counters should be brief and contain no underscores.
24
25 - No variable names should be only one letter, since then they are
26   difficult to search for in an editor.
27
28 - Integers variables beginning with "n" or "i" should either contain
29   no underscores (e.g. "naerosoltypes"), or should have an underscore
30   immediately after the "n" or "i" (e.g. "n_aerosol_types"). Thus, a
31   variable beginning with "n" or "i" containing an underscore but not
32   as its second character need not be an integer (would normally then
33   be a real or a derived type), in order to enable real variables
34   such as "ice_water_content".
35
36 - All variables and procedure names in lower case using descriptive
37   names, and if not too long these will be composed of complete words
38   separated by underscores.
39
40 - All parameters are in CamelCase, and integer parameters are
41   prefixed by "I" or "N".
42
43 - C-style enumerations (using "enum, bind(c)" and "enumerator")
44   should be preferred over integer parameters when they refer to a
45   specific setting, because "if (solver_sw==ISolverTripleclouds)" is
46   clearer than "if (solver_sw==5)".
47
48 - Variable character strings are suffixed by "_name" or "_str", while
49   parameter character strings (in CamelCase) are suffixed by "Name"
50   or "Str".
51
52 - Global data included in modules must be constant; any variable data
53   must be passed to procedures via dummy arguments.
54
55 - Long argument lists avoided by grouping variables thematically into
56   derived types.
57
58 - Any variable used in a source file should be defined in a comment
59   earlier in the source file (if this is not obvious from the
60   variable name) including its units if it has them (even if they are
61   SI units).
62
63 - All functions and subroutines to be defined in modules and their
64   explicit interfaces to be revealed via the "use" command, which
65   should use "only".
66
67 - Data are read in at run-time from NetCDF files rather than being
68   embedded in the code (e.g. using data statements).
69
70 - Fortran "statement functions" should not be used.
71
72 - "if" statements should always be followed by "then" with the action
73   given on the next line, rather than one-line if statements.
74
75 - "end" should always be followed by a space, i.e. "end do" ,"end if"
76   rather than "enddo", "endif"
77
78 - Lots of comments!
Note: See TracBrowser for help on using the repository browser.