[5037] | 1 | # Coding Rules |
---|
| 2 | |
---|
| 3 | The conventions used in SIREN coding are based on the NEMO coding rules |
---|
| 4 | (see [NEMO coding |
---|
| 5 | conventions](http://www.nemo-ocean.eu/content/download/15483/73221/file/NEMO_coding.conv_v3.pdf)).<br/> |
---|
| 6 | However some modifications were added to improve readibility of the code.<br/> |
---|
| 7 | Some of the NEMO coding rules are reminded here, and extensions are described. |
---|
| 8 | |
---|
| 9 | @tableofcontents |
---|
| 10 | |
---|
| 11 | # Fortran Standard {#std} |
---|
| 12 | |
---|
| 13 | SIREN software adhere to strict __FORTRAN 95__ standard.<br/> |
---|
| 14 | There is only one exception. The use of functions _COMMAND_ARGUMENT_COUNT_ and |
---|
| 15 | _GET_COMMAND_ARGUMENT_.<br/> |
---|
| 16 | There exist no equivalent for those Fortran 03 intrinsec functions in Fortran |
---|
| 17 | 95.<br/> At least none convenient for compilers tested (see @ref md_docsrc_1_install). |
---|
| 18 | |
---|
| 19 | # Free Form Source {#free} |
---|
| 20 | Free Form Source will be used, however a self imposed limit of 80 should |
---|
| 21 | enhance readibility. |
---|
| 22 | |
---|
| 23 | # Indentation {#indent} |
---|
| 24 | Code as well as comments lines will be indented 3 characters for readibility.<br/> |
---|
| 25 | __Indentation should be write without hard tabs__. |
---|
| 26 | |
---|
| 27 | Example for vi : |
---|
| 28 | ~~~~~~~~~~~~~~~~~~~~~ |
---|
| 29 | :set expandtab tabstop=3 shiftwidth=3 |
---|
| 30 | ~~~~~~~~~~~~~~~~~~~~~ |
---|
| 31 | |
---|
| 32 | # Naming conventions : variable {#namvar} |
---|
| 33 | All variables should be named as explicitly as possible.<br/> |
---|
| 34 | The naming conventions concerns prefix letters of these name, in order to |
---|
| 35 | identify the variable type and status.<br/> It must be composed of two |
---|
| 36 | letters defining type and status follow by an underscore.<br/> |
---|
| 37 | table below list the starting letters to be used for variable naming, |
---|
| 38 | depending 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} |
---|
| 51 | The structure name should be written in capital letter, and start with |
---|
| 52 | __T__<br/> Example: TTRACER <br/> |
---|
| 53 | Variables inside the structure should be named as explicitly as possible.<br/> |
---|
| 54 | For those variables, the prefix naming conventions only concern the type of variable.<br/> |
---|
| 55 | It must be composed of one letter defining type follows by an |
---|
| 56 | underscore.<br/> |
---|
| 57 | see table of variable conventions.<br/> |
---|
| 58 | |
---|
| 59 | Example: __tl\_type\%i\_year__<br/> _year_ is an integer(4) variable in a local strucure |
---|
| 60 | named _type_. <br/> |
---|
| 61 | |
---|
| 62 | # Naming conventions : function-subroutine {#namsub} |
---|
| 63 | Functions or Subroutines are defined in a module.<br/> |
---|
| 64 | Their name should start with the module name then with their "functional" name. So it will be |
---|
| 65 | easy to find it.<br/> |
---|
| 66 | Example:<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/> |
---|
| 74 | Numerical constant need to have a suffix of __kindvalue__ |
---|
| 75 | |
---|
| 76 | # Declaration for global variable and constants {#global} |
---|
| 77 | All global data must be accompanied with a comment field on the same |
---|
| 78 | line.<br/> |
---|
| 79 | _Note that using doxygen (see [header](#header)), we will use symbol !< instead of !: as separator_ |
---|
| 80 | |
---|
| 81 | # Implicit none {#implicit} |
---|
| 82 | All subroutines and functions will include an IMPLICTI NONE statement. |
---|
| 83 | |
---|
| 84 | # Header {#header} |
---|
| 85 | |
---|
| 86 | SIREN use __doxigen auto documentation__ tool.<br/> |
---|
| 87 | Information could be find on |
---|
| 88 | [doxygen](http://www.stack.nl/~dimitri/doxygen/index.html) web page.<br/> |
---|
| 89 | Some 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> |
---|