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.
4_codingRules.md in branches/UKMO/dev_r5518_test_GO6_package_update/NEMOGCM/TOOLS/SIREN/src/docsrc – NEMO

source: branches/UKMO/dev_r5518_test_GO6_package_update/NEMOGCM/TOOLS/SIREN/src/docsrc/4_codingRules.md @ 7877

Last change on this file since 7877 was 7877, checked in by frrh, 7 years ago

Merge missing swathe of revisions from branches/2015/nemo_v3_6_STABLE/NEMOGCM
using the command:
svn merge -r6424:6477 svn+ssh://forge.ipsl.jussieu.fr/ipsl/forge/projets/nemo/svn/branches/2015/nemo_v3_6_STABLE/NEMOGCM

Note: this required manual conflict resolution of the content of NEMOGCM/TOOLS/SIREN/src/docsrc/
since the existing contenets of those directories in the package branch are not consistent
with the contents of branches/2015/nemo_v3_6_STABLE at revision 6424. (This should be an
incidental matter as the content in question only relates to documentation of NEMO tools
and is not relevant to NEMO source code.)

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_src_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_src_docsrc_1_install
96   - @ref md_src_docsrc_2_quickstart
97   - @ref md_src_docsrc_3_support_bug
98   - @ref md_src_docsrc_5_changeLog
99   - @ref todo
100   </b>
Note: See TracBrowser for help on using the repository browser.