WW3 Code Style Standards

White Space

• No tabs
• No blank spaces at the end of lines
• Indention:
  • 2 spaces will be used for indentation
  • Open statements (ie if/do) should align with their closing statements (end)
  • The first 6 columns will no longer be reserved for spaces (ie no more fixed-format fortran)
• For consistency, no space between '#' and the corresponding 'if' or 'end' statements

Line Length

• The preference is to keep line length under 80 characters although up to 100 can be used by code or 120 by comment lines.

GOTOs:

• Do not add computed GOTOs
• Limit additional GOTOs

Modules

• Use “only” statements for any new module use statements
  • There will not be a concentrated effort to go back and update existing code from the code managers, updates doing this are welcomed from developers and any new code will be required to follow this.
• No implicit variables are allowed, i.e. use “implicit none”.

Documentation, Headers, Code Comments

• Moving forward the “WW3 headers are not required, while updates to remove existing headers is welcome, there will be no effort to remove all headers from the code. If you are removing an existing WW3 header, please take special care to ensure that relevant information is retained either via the doxygen header or in code comments.
• Doxygen will be used to document the code.
  • Any new subroutine, program or module must have doxygen. Information on WW3 doxygen requirements can be found in the WW3 Doxygen Templates.
  • Efforts are being made to include doxygen in all existing WW3 code.
• Please add good code comments. While “good” code comments is a subjective term, some examples are:
  • Provide references where appropriate.
  • Describe any code that might be interpreted to be “confusing”
  • Define variables

Capitalization

• The previous WW3 standard was that ‘permanent’ code used ALL CAPS and temporary code used all-lowercase. Moving forward, mixed-capitalization for new code will be allowed. There will be no effort to update existing code capitalization styles.

Naming Conventions

• Programs file names should start with ww3_
• Modules and subroutines file names should start with:
  • wm for multi- related shared subroutines and modules
  • w3 for all other files
• Variable names should be descriptive and are no longer required to meet the old 6 character fortran length. (Don’t forget to document their meaning through doxygen!)

General “Good Practice”

While no effort is being made to update existing code, moving forward the following items, which are considered ‘good practice’ should be followed:

• Pointer arrays in derived types should be initialized to null() unless immediately assigning it a value after declaration
• Pointer arrays that are module variables should be initialized to null()
• Fortran intrinsic procedure names should not be used as variable names (eg. using "write" or "status" as a variable name)
• Hardwired values should be avoided. Using a local variable allows the value to be changed in a single location rather than many locations
• Use utility routines when possible