New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
3_codingRules.md in branches/UKMO/dev_r5518_v3.6_asm_nemovar_community/NEMOGCM/TOOLS/SIREN/src/docsrc – NEMO

source: branches/UKMO/dev_r5518_v3.6_asm_nemovar_community/NEMOGCM/TOOLS/SIREN/src/docsrc/3_codingRules.md @ 7731

Last change on this file since 7731 was 7731, checked in by dford, 7 years ago

Merge in revisions 6625:7726 of dev_r5518_v3.4_asm_nemovar_community, so this branch will be identical to revison 7726 of dev_r5518_v3.6_asm_nemovar_community.

File size: 4.5 KB
Line 
1# Coding Rules
2
3The conventions used in SIREN coding are based on the NEMO coding rules
4(see [NEMO coding
5conventions](http://www.nemo-ocean.eu/content/download/15483/73221/file/NEMO_coding.conv_v3.pdf)).<br/>
6However some modifications were added to improve readibility of the code.<br/>
7Some of the NEMO coding rules are reminded here, and extensions are described.
8
9@tableofcontents
10
11# Fortran Standard {#std}
12
13SIREN software adhere to strict __FORTRAN 95__ standard.<br/>
14There is only one exception. The use of functions _COMMAND_ARGUMENT_COUNT_ and
15_GET_COMMAND_ARGUMENT_.<br/>
16There exist no equivalent for those Fortran 03 intrinsec functions in Fortran
1795.<br/> At least none convenient for compilers tested (see @ref md_docsrc_1_install).
18
19#  Free Form Source {#free}
20Free Form Source will be used, however a self imposed limit of 80 should
21enhance readibility.
22
23#  Indentation {#indent}
24Code as well as comments lines will be indented 3 characters for readibility.<br/>
25__Indentation should be write without hard tabs__.
26
27Example for vi  :
28~~~~~~~~~~~~~~~~~~~~~
29:set expandtab tabstop=3 shiftwidth=3
30~~~~~~~~~~~~~~~~~~~~~
31
32#  Naming conventions : variable {#namvar}
33All variables should be named as explicitly as possible.<br/>
34The naming conventions concerns prefix letters of these name, in order to
35identify the variable type and status.<br/> It must be composed of two
36letters defining type and status follow by an underscore.<br/>
37table below list the starting letters to be used for variable naming,
38depending on their type and status.
39
40 | Type / Status     | byte (integer(1)) <br/> __b__ | short (integer(2)) <br/> __s__ | integer(4) <br/> __i__  | integer(8) <br/> __k__ | real(4) <br/> __r__ | real(8) <br/> __d__ | logical <br/> __l__ | character <br/> __c__ | complex <br/> __y__ | structure <br/> __t__  |
41 | :----:            | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: | :----: |
42 |global <br/> __g__           | bg_  | sg_  | ig_  | kg_  | rg_  | dg_  | lg_  | cg_  | yg_  | tg_  |
43 |global parameter <br/> __p__ | bp_  | sp_  | ip_  | kp_  | rp_  | dp_  | lp_  | cp_  | yp_  | tp_  |
44 |module <br/> __m__           | bm_  | sm_  | im_  | km_  | rm_  | dm_  | lm_  | cm_  | ym_  | tm_  |
45 |namelist <br/> __n__         | bn_  | sn_  | in_  | kn_  | rn_  | dn_  | ln_  | cn_  | yn_  | tn_  |
46 |dummy argument <br/> __d__   | bd_  | sd_  | id_  | kd_  | rd_  | dd_  | ld_  | cd_  | yd_  | td_  |
47 |local <br/> __l__            | bl_  | sl_  | il_  | kl_  | rl_  | dl_  | ll_  | cl_  | yl_  | tl_  |
48 |loop control       |      |      | j?   |      |      |      |      |      |      |      |
49
50# Naming conventions : structure {#namstr}
51The structure name should be written in capital letter, and start with
52__T__<br/> Example: TTRACER <br/>
53Variables inside the structure should be named as explicitly as possible.<br/>
54For those variables, the prefix naming conventions only concern the type of variable.<br/>
55It must be composed of one letter defining type follows by an
56underscore.<br/>
57see table of variable conventions.<br/>
58
59Example: __tl\_type\%i\_year__<br/> _year_ is an integer(4) variable in a local strucure
60named _type_. <br/>
61
62# Naming conventions : function-subroutine {#namsub}
63Functions or Subroutines are defined in a module.<br/>
64Their name should start with the module name then with their "functional" name. So it will be
65easy to find it.<br/>
66Example:<br/> a function to realise addition written in a module
67__math__ should be called __math\_add__.<br/>
68
69__PUBLIC__  function or subroutine should used one undescrore: _math_add_<br/>
70__PRIVATE__ function or subroutine should used two undescrores: _math__add_<br/>
71
72# Precision {#precision}
73__All variables should make use of kinds__.<br/>
74Numerical constant need to have a suffix of __kindvalue__
75
76# Declaration for global variable and constants {#global}
77All global data must be accompanied with a comment field on the same
78line.<br/>
79_Note that using doxygen (see [header](#header)), we will use symbol !< instead of !: as separator_
80
81# Implicit none {#implicit}
82All subroutines and functions will include an IMPLICIT NONE statement.
83
84# Header {#header}
85
86SIREN use __doxigen auto documentation__ tool.<br/>
87Information could be find on
88[doxygen](http://www.stack.nl/~dimitri/doxygen/index.html) web page.<br/>
89Some basic tag are described
90[here](http://www.msg.chem.iastate.edu/gamess/DoxygenRules.oct10.pdf).
91
92 <HR>
93   <b>
94   - @ref index
95   - @ref md_docsrc_1_install
96   - @ref md_docsrc_4_changeLog
97   - @ref todo
98   </b>
Note: See TracBrowser for help on using the repository browser.