Coding Conventions

Fortan

Discouraged Functions and Syntax

line numbers

They are a relict of the deprecated goto statement and not needed.

write(*,*)

A print* statement is easier to read than write(*,*).

return

This statement is superfluous at the end of a subroutine/function.

.lt., .le., .eq., .ne., .gt., and .ge.

The more readable comparison symbols <, <=, ==, !=, >, and >= are preferred.

(/ and /)

The more readable [ and ] are preferred.

Data Declaration

Modules

  • Public variables are discouraged in favor of object-oriented get and set functionality.

  • Unless the whole module is public, implicit none needs to be followed by private.

Functions

  • Functions have no intent(out) or intent(inout) dummy variables.

  • Functions without side effects should be declared pure.

  • Possible specifications of return value

    • real(pReal) | integer [pure] function f(...)

    • [pure] function f(...) result (res)

  • Variable declarations follow the order

    1. intent(in)

    2. result

    3. local variables

Subroutines

  • Subroutines without side effects should be declared pure.

  • Subroutine dummy arguments are sorted

    1. intent(out)

    2. intent(inout)

    3. intent(in)

  • Variable declarations follow the order

    1. intent(in)

    2. intent(inout)

    3. intent(out)

    4. local variables

Naming Scheme

  • Global variables are prefixed by the name of the module.

  • Parameters are written in CAPITALS.

Common Variable Names

  • ho: homogenization ID

  • ph: phase ID

  • en: entry

  • ce: cell

  • co: constituent

  • el: element

  • ip: integration point

Indentation and Line Format

  • No indentation for modules/programs and functions/subroutines.

  • Two spaces (no tab stops) per each additional level.

  • Line should end around 100 characters; a 132 character limit is enforced.

  • OpenMP directions maintain the current indentation level.

Code Documentation

  • Functions, variables, and parameters are described by doxygen tags.

  • Readable code (e.g. explanative variable names) is preferred over in-line comments.

Recommendations

  • Nested control structures (do, if, where, or select case) should be named.

      IncLooping: do i = 1_pInt, 10_pInt
        subIncLooping: do s = 1_pInt, 1000_pInt
          a = a + time(i,s)
        enddo subIncLooping
        a = 1/a
    enddo IncLooping
    

    instead of

      do i = 1_pInt, 10_pInt
        do s = 1_pInt, 1000_pInt
          a = a + time(i,s)
        enddo
        a = 1/a
    enddo
    
  • Field initialization with spread is preferred over explicit loops.

    real(pReal), dimension(3,3,10) :: a
    
    a = spread(math_I3,3,10)
    

    instead of

    real(pReal), dimension(3,3,10) :: a
    
    a = 0.0_pReal
    do i = 1_pInt, 10_pInt
      a(1:3,1:3,i) = math_I3
    enddo
    
  • Calculations over entire fields should use intrinsic functions (such as sum or prod) instead of explicit loops.

    real(pReal), dimension(3,3,10) :: a
    real(pReal), dimension(3,3)    :: b
    
    b = sum(a)
    

    instead of

    real(pReal), dimension(3,3,10) :: a
    real(pReal), dimension(3,3)    :: b
    
    b = 0.0_pReal
    do i = 1_pInt, 10_pInt
      b = b + a(1:3,1:3,i)
    enddo
    
  • Explicit range specifications are preferred over assumed size/shape.

    integer(pInt), dimension(3,3,5,5) :: field
    integer(pInt), dimension(3,3)     :: tensor
    
    field(1:3,1:3,1,1) = tensor
    

    instead of

    integer(pInt), dimension(3,3,5,5) :: field
    integer(pInt), dimension(3,3)     :: tensor
    
    field(:,:,1,1) = tensor
    

Resources

Python