Voir la source de HowTo: LMDZ code guidelines

  /!\ This page is a WORK IN PROGRESS. Nothing in this page should be considered correct or consensual for now. /!\

== Example code ==

''Note: in this example, we added "meta-comments" indicated by <code>!!</code>''

''Note: of course, there's always exceptions to "Always", but they should '''systematically''' documented by a comment, with a proper explanation.''


 !! File: lmdz_mymodule.f90
 !!         ^ all module files should start with their component name, (e.g. "lmdz")
 !!                      ^ use ".f90" for all free-form files, unless they contain preprocessor directives (then use ".F90").
 
 !! At the top of the file, we provide a comment to explain what this modules does
 ! implementation of my_useful_stuff.
 ! ----------------------------------
 
 !! Unless specified otherwise, all files should contain a single module which encapsulates all their content
 MODULE my_module
 !!  ^ all Fortran keywords are in CAPS, everything else is in lowercase.
   USE my_other_module, ONLY: function_a, function_b
   !!                     ^ Always specify explicitely which functions you use from a module.
!!^ use indentation (2 spaces) to provide visual clarity
   IMPLICIT NONE; PRIVATE
   !!                ^ Always make your module private, and expose explicitely which functions are public
   !!    ^ Always use IMPLICIT NONE at the module-level
   PUBLIC my_var, my_subroutine
 
   REAL, PARAMETER :: my_var
   REAL            :: a, b, c, d, e, f
   !!               ^ use "::" even if it's not strictly necessary
   !!       ^ Alignment of "::" is not necessary, but should be attempted whenever it provides readability and is relevant (e.g. there's some link between the aligned variables)
         
 CONTAINS
   
  !! Put at least a blank line before/after each function/subroutine
   SUBROUTINE my_subroutine(arg1, arg2, arg3) ! handle event xxxx
   !!                            ^ comments should always be right before, or on the same line as what they're commenting
   !!                            ^ as for modules, all functions should be documented in a comment
     INTEGER, INTENT(IN) :: arg1
     !!          ^ Always provide intent 
     REAL, INTENT(IN)    :: arg2


     INTEGER, INTENT(INOUT) :: arg3

     REAl, INTENT(OUT) :: out1
     !!^ Group together IN, then INOUT, then OUT

     ! ... body of my_subroutine
   END SUBROUTINE my_subroutine
!!         ^ always use named blocks for END
   
 
 END MODULE my_module
 !!       ^ always use named blocks for END



Some comments:
* Limit '''to the bare minimum''' the use of preprocessor <code>#ifdef</code> keys. Those decrease lisibility, disable automatic code analysis, and generally make code a pain to manage and read. Ideally, a given preprocessor key should be used only once, or if not possible, in a single module for the entire codebase.
* Limit the use of <include> headers to the bare minimum. Whenever not possible, wrap those include in a module, and import that module instead. This provides much more flexibility, e.g. when using <code>ONLY: ...</code>.