Skip to end of metadata
Go to start of metadata

>>Terms of Use
>>Go BACK to previous page.

This page is intended as a guide for CLM coding standards, practices and conventions. On this page, we focus on five items that we want all developers to concentrate on. Keep these in the back of your mind as you are programming and refer to them if you have a question. We are more than willing to work with you throughout the process (contact us at If code doesn't generally conform to these items then it will delay the tagging process and we will ask you to modify your code accordingly.

Our past experiences have led us to document a more Comprehensive list of standards that we are striving for. You will find constructs that do not follow these guidelines and we are updating the legacy CLM code base as time and resources permit.


  1. Comment often and include explanations for algorithms and processes. Your code should be easily readable and understandable by anyone else who reads your work.
    1. Logical Branches - include a comment after an else or endif statement. Use something that makes sense for the type of logical branch you are using. This is particularly important when there are large numbers of nested blocks.

      Comments and Logical Branches
    2. Pointer Intent - If you pass information to a subroutine via a pointer in an associate block, include a comment as to the intent (OUT, IN, INOUT) of that pointer. This is in addition to a description of that pointer as well as the type and array dimensions. Also see Argument Passing on this page.

      Comments and Pointer Intent
      1. The meaning (semantic) of intent (out, in, inout)
        1. out - a variable is only set within a subroutine
        2. in - a variable is only passed into and used by a subroutine
        3. inout - a variable may be both modified and used within a subroutine

Argument Passing

  1. The intent attribute of subroutine input/output variables is used. Argument lists should always use the intent attribute (try to have data be either IN or OUT and avoid INOUT if possible/reasonable).
  2. There are currently three ways in the current code with which you can pass information to subroutines. By interface (best choice), by pointer (second best choice) and by using a global data type (a bad option, but sometimes still necessary within the current CLM framework). We are in the process of refactoring the code so that all data will be passed through the subroutine interface. New code coming in should not pass via global data unless all other options do not work.
    1. Subroutine Interface - Use the intent keyword and keyword pairs if you have more than a few arguments. Try to consistently pass either all derived types or all FORTRAN types. Passing derived types can shorten the list of arguments and make it more understandable. Below are two examples from CLM, (subsection i, below) and RTM, (subsection ii, below), respectively.
      1. CLM example from BandDiagonal::BandDiagonalMod.F90
        1. Subroutine definition

          Interfaces::CLM. Example from BandDiagonal, definition
        2. The definition above illustrates a few important points.
          • Specify the lower bounds of array arguments (this is needed for the subroutine to operate properly in a threaded region)
          • Do not specify the upper bounds of array arguments (doing so can prevent the compiler from checking for array size agreement between the caller and callee, and can carry a performance penalty)
          • The first set of code in the routine should be assertions for the expected array upper bounds
        3. The above code demonstrates a few stylistic points as well:
          • Specify the lower bound explicitly, even when it is 1 (see the 'b' argument, above)
          • Put a space after each ':' for readability
          • Add comments about expected array sizes, as in [col, nband, j]
        4. Subroutine call
          Follow this example in which BandDiagonal is called from SoilTemperatureMod.F90:

          Interfaces::CLM. Example from BandDiagonal, call
          • The important point here is that the lower and upper bounds are explicitly specified for the gridcell / landunit / col / pft dimension of all array arguments. This is important for threading to work properly.
          • Even for local variables whose dimensions only go begc:endc, please explicitly specify the dimensions as above when passing the array to a subroutine. This will ensure that threading continues to work if the variable's dimensions change (e.g., if it is pulled into clmtype, and thus has dimensions that span the proc_bounds rather than the clump_bounds).
      2. RTM example from RtmMod.F90

        Interfaces::RTM. Example from RtmMod.F90
    2. Pointer - We are moving away from using pointers as a way pass information into routines. We still allow this but with the use of an associate statement.

      Comments and Pointer Intent
    3. Global data - We are moving away from using global data as a way pass information into routines. Unless you are extending existing functionality (e.g. using a namelist variable to control some execution) we will generally not allow any new use of a global variable. The other exception to this rule is that it is OK to you use global type declarations.

      Global Data. Global data in CanopyFluxesMod.F90
      Global Data. Using a global type declaration


  1. Indent consistently and make sure your auto-tab function in your editor converts tabs to spaces.
    1. Indent of most blocks (do, if, while, etc.): 3 spaces
    2. Indent of "program" blocks (program, module, subroutine, function): 2 spaces
    3. Indent of "associate" blocks: 0 spaces
    4. Indent of continuation lines: 5 (this can vary based on look and feel)


Statements and Subroutines

  1. Don't repeat yourself. If you are copying and pasting code, then write a subroutine or function to encapsulate functionality.

    Example of repeated code - Do
    Example of repeated code - Don't do
  2. Fortran allows you to place multiple statements on one line. Don't do this.

    Multiple Statements - Do
    Multiple Statements - Don't do
  3. Use temporary variables often

    Temporary Variables - Do
    Temporary Variables - Don't do
  4. Keep subroutines short and organize the code into the smallest reasonable chunk of code that can stand on its own. Basically, you're looking for dividing routines into logical units of work. For example, don't put initialization, some science and then diagnostics all in one routine, these would be best divided into 4 routines; in this case one routine that calls three additional routines.
    • Use parenthesis to clarify you statements even when the Fortran precedence rules will evaluate items in the correct order.

Preprocessor Macros (CPP Tokens)

  • We are in the process of removing CPP Tokens from all of CLM (see our refactoring page ) and will not accept code using them.

    Preprocessor Macros (CPP Tokens) - Do
    Preprocessor Macros (CPP Tokens) - Don't do
  • No labels