GSI Code Standards

Before any changes will be merged from a branch back into develop, the following coding standards MUST be met.

NCO Code Standards

Please refer to Implementation Standards for the most recent standards and requirement document from NCO. Since NOAA-EMC/GSI only support current or planned operational implementations, all changes must adhere to NCO Code Standards.

• NCO requires that all goto (go to) statements be removed from operational Fortran codes.

GSI Code Standards

Constants & Conversions:

• Use globally defined constants from the constants module (constants.f90)
• Explicitly specify precision of local numeric constants (e.g., use 10.0_r_kind instead of 10.0)
• You are no longer required to use _i_kind on integers.
• When converting between variable types, use fortran intrinsic functions. For example, vars_r_single = real(vard_r_double,r_single)

OMP Directives:

• All OMP directives must have private variables designated i.e. !$omp parallel do private(i,j,k)

Declarations:

• All routines must include "implicit none"
• All module declarations must explicitly specify which module components (variables or routines) are used within the given routine (e.g., use constants, only: zero, one, two)
• All integer and real variables must be typed using type definitions in the kinds module (kinds.f90)
• The INTENT attribute must be specified for all arguments passed into and out of procedures (subroutines and functions)
• Unused variables must be removed from the code. Unused variables trigger compiler warnings. NCO requires codes to compile without compiler warnings.

Allocated Arrays:

• All arrays explicitly allocated, must be deallocated when no longer needed.

Documentation:

• All subroutines must have a documentation block at the head of each subroutine or function
• Document all changes, not only around modified code but also in the documentation block (doc block)
• Ensure input/output argument documentation in doc block is consistent with additions/deletions from calling list
• Do not label changes with user names or initials (e.g., !XZ changes below)

Free format code:

• Use 3 space indentation for all do and if loops
• Use <, <=, >, >=, ==, or /= ... moving away from .lt., .le., .gt., .ge., .eq., .ne.
• Maximum line length of 132 characters
• Use if(logic_variable)then, not if(logical_variable ==.true.)then
• If using integers as logicals, explicitly state (e.g., if(icw4crtm /= 0)then)
• Ensure character lengths match what is explicitly declared
• Unused code should be removed. Doing so improves code readability. Since the code is version controlled, removed code can be recovered, if needed, from a previous hash.

Modules:

• Add private and public declarations to module contents

Debugging code:

• All code intended for debugging purposes only should be removed prior to submission for inclusion on trunk

Tangent Linear and Adjoint Naming Convention:

• To make the location of tangent linear and adjoint variables and routines easier for developers, a standard naming convention has been established for these routines. For tangent linear and adjoint routines and / or variable names are the suffixes “_tl” and “_ad”, respectively. Other naming conventions will not be accepted.

Namelist Options/Variables

• Within gsimod.F90, whenever a new namelist variable is added, please ensure that the new variable is added to the correct namelist option and that it is sufficiently defined and explained.
• When adding new science to the code, please refrain from using ifdefs. There are a quite a few ifdefs in the code right now and there are projects to reduce the number of these. Adding a new namelist variable and using if/then statements or other methods should be used in these instances.