Fortran Best Practices

Analogy categoryAnalogies

Writing Modern, Maintainable Fortran

Modern Fortran (2003 and later) supports the same engineering discipline expected in any production language: strict typing, modular design, and explicit interfaces. The single most important habit is starting every program unit with implicit none, which forces you to declare every variable and immediately surfaces typos that would otherwise silently create a new real-valued variable starting with a letter i-n. Pairing this with free-form source (.f90) and module-based organization instead of legacy INCLUDE files gives the compiler enough information to catch argument-mismatch bugs at compile time rather than producing garbage results at runtime.

🏏

Cricket analogy: Just as a batsman takes strict guard and checks the field before facing a ball, implicit none forces every variable's type to be declared up front, so a mistyped name is caught the way a sharp umpire calls a no-ball before it counts.

Module Organization and Interfaces

Group related procedures and data into modules and use them explicitly rather than relying on legacy COMMON blocks or bare INCLUDE statements. Modules automatically generate explicit interfaces for their contained procedures, so the compiler verifies argument count, type, and rank at every call site — a class of bugs that plagued FORTRAN 77 codebases for decades. Keep modules focused: a linear_algebra_mod should export solver routines, not unrelated I/O helpers, so dependency graphs between compilation units stay shallow and rebuilds stay fast.

🏏

Cricket analogy: This is like the IPL splitting a squad into specialists — an opener, a middle-order anchor, a death bowler such as Jasprit Bumrah — instead of one undefined blob; modules give each Fortran unit a clear, checkable role.

Memory and Array Best Practices

Prefer allocatable arrays over pointers for owned, dynamically sized data — allocatables have deterministic deallocation and cannot alias each other, eliminating a whole class of memory leaks and dangling references. Use whole-array and array-section syntax such as a(:,:) = b(:,:) + c(:,:) instead of manual nested loops where clarity matters, but profile before assuming the compiler auto-vectorizes; sometimes an explicit do concurrent or OpenMP loop outperforms implicit array syntax on a given target architecture.

🏏

Cricket analogy: Choosing allocatable arrays over pointers is like fielding a fixed playing XI the team fully owns, instead of loan players who could be recalled mid-series, so nothing aliases unexpectedly.

fortran

module linear_algebra_mod
  use, intrinsic :: iso_fortran_env, only: rk => real64
  implicit none
  private
  public :: dot_product_safe

contains

  function dot_product_safe(a, b) result(s)
    real(rk), intent(in) :: a(:), b(:)
    real(rk) :: s
    integer :: n

    n = size(a)
    if (n /= size(b)) then
      error stop 'dot_product_safe: array size mismatch'
    end if
    s = sum(a(1:n) * b(1:n))
  end function dot_product_safe

end module linear_algebra_mod

Never leave an allocatable array's status unchecked before use. Reading or writing to an unallocated allocatable, or reallocating without deallocating first in older compilers, produces undefined behavior. Always guard with if (allocated(x)) then before deallocation and prefer automatic (re)allocation on assignment, a Fortran 2003 feature most compilers now support correctly.

Precision and Numerical Safety

Never hard-code compiler extensions like real*8 to request double precision — they are non-standard and vary in meaning across compilers. Instead, use iso_fortran_env's real64/real32 kind constants or selected_real_kind to request a precision and range explicitly, then propagate that kind parameter through every declaration in the program via a single shared module. This makes switching the entire codebase from single to double precision, or to quad precision for a sensitive solver, a one-line change instead of a error-prone global search and replace.

🏏

Cricket analogy: Using real64 from iso_fortran_env instead of real*8 is like using the official ICC-certified pitch measurements instead of a groundskeeper's rough guess, so every venue reports distances in the same standard unit.

Prefer selected_real_kind(p, r) when you need to state precision and range requirements portably (for example, selected_real_kind(15, 307) for IEEE double), and prefer the simpler iso_fortran_env constants real32/real64/real128 when you just want the common IEEE formats by name.

Error Handling and I/O

Never let a failed READ, WRITE, ALLOCATE, or OPEN statement propagate silently. Attach iostat=/stat= and iomsg=/errmsg= arguments and check the returned status immediately, branching to a clear diagnostic and controlled exit rather than letting the program continue with corrupted or undefined data. For allocation failures specifically, allocate(x(n), stat=ierr, errmsg=msg) lets you report a meaningful out-of-memory message instead of crashing with a bare runtime trap that gives the user no context.

🏏

Cricket analogy: Checking iostat after every read is like a third umpire reviewing every close run-out before the scoreboard updates, rather than letting a bad decision stand and corrupt the match record.

Always start modules and programs with implicit none to force explicit variable declarations.
Organize code into focused modules with use, not COMMON blocks or bare INCLUDE files.
Prefer allocatable arrays over pointers for owned data; they cannot alias and deallocate deterministically.
Use iso_fortran_env kind constants or selected_real_kind instead of compiler extensions like real*8.
Check stat=/iostat= on every ALLOCATE, READ, WRITE, and OPEN statement.
Use whole-array syntax for clarity but profile before assuming it auto-vectorizes.
Keep module public interfaces minimal with private by default and explicit public :: exports.