= PALM coding rules =
Why to follow some standards? - Because everyone has her/his own programming style, sort of a dialect. And as it is, no one can understand all the possible dialects. So what do we do? We learn and apply the coding standard to make PALM more easily readable for all current and future developers. Let's all work on that - together.

== General ==
* Only ASCII characters allowed
* Line length limit: 80 (soft) | 120 (hard)

== Indenting, spaces & line breaks ==
'''__General module/subroutine structure'''
(see Fig. 1)
{{{
#!div style="align:'left'; width: 450px; border: 0px solid; float:right"
[[Image(rules_indent_general.png, 450px, right, margin-right=2, margin-top=0, border=0)]]\\
Fig. 1 Indention example with highlighted whitespaces. Click to enlarge.
}}}

* '''0 whitespace''' in front of pre-processor directives
* '''1 whitespace''' before MODULE, CONTAINS, SUBROUTINE (= first indention level)
* '''+3 whitespaces''' for all following indention levels \\(only exception: ONLY list in USE statements '''+4 whitespaces''')\\

* '''1 whitespace''' between individual strings, and between strings and symbols/numbers
* '''1 whitespace''' after ''','''\\(only exception: '''0 whitespace''' between array dimensions)
* '''1 whitespace''' before '''::''' \\(at minimum, see Sect. [#align Alignment])
* '''2 whitespace''' after ''':''' and '''::'''\\

* '''1 blank line''' between enclosed blocks of instructions, assignments, clauses, statements, etc.
* "&" character for line continuation at position 80 (minimum), max at position 120

'''__Whitespaces between brackets'''
(see Fig. 1)
* '''0 whitespace''' between string and '''('''
* '''1 whitespace''' after '''(''' and before ''')'''\\(only exception: '''0 whitespace''' in dimensions)

\\\\\\\\\\\\\\\\\\\\\\\\
'''__Whitespaces in DO, IF blocks'''
(see Fig. 2)
{{{
#!div style="align:'left'; width: 450px; border: 0px solid; float:right"
[[Image(rules_indent_loops.png, 450px, right, margin-right=2, margin-top=0, border=0)]]\\
Fig. 2 Indention & whitespaces in loops. Click to enlarge.
}}}

* In general: '''1 whitespace''' everywhere and '''3 whitespace''' for indention levels
* But: '''2 whitespace'''\\
  * between '''DO''' and '''loop index'''
  * after '''IF (  )''' --> see {{{CALL}}}, {{{THEN}}}
  * in front of and after logical or relational operators (e.g. '''.OR.''', see [#operators list of allowed operators])


\\\\\\\\\\\\\\\\\\\\\\\\\\
== Alignment ==
(see Fig. 3)
{{{
#!div style="align:'left'; width: 450px; border: 0px solid; float:right"
[[Image(rules_align.png, 450px, right, margin-right=2, margin-top=0, border=0)]]\\
Fig. 2 Indention & whitespaces in loops. Click to enlarge.
}}}
* Block-wise alignment of continuation line marker '''&'''
* Alignment of ONLY lists
* At least block-wise alignment for same type/group of declaration statement
* Alignment of message_string values
* Alignment of input between brackets (e.g. in '''IF (  )  THEN''' or in argument list in subroutine calls)

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
== Alphabetical sorting ==
except for CALLs to modules/subroutines

== Lower/upper case ==

== Commenting ==

== Naming conventions ==

== Operators ==
* e.g. /=, <, <=, ==, >, >=, etc. (not .GE., .LT., etc)
* .AND., .OR., .NOT.

== Preprocessor directives ==

== File header ==
* Files always start with a doxygen-readable comment line including the FORTRAN file name.
* This is followed by the license section. If your code originates from another model, please clarify the license and permissions for this code to enter the PALM model system. It might be necessary in that case to add some more information to this header.
* The revisions section will later include short notes of the changes applied to a specific svn revision of this file. The {{{$Id$}}} string is required so that svn knows to generate the respective time stamp for a revision (see existing SOURCE files).
* Finally, involved authors are included, followed by a description of the purpose and functions of the module. If necessary, TODOs, notes and known bugs can be added. The "!>" indicate doxygen-readable comment lines, the "@" marks doxygen variables.