Developers:Code style

From OctopusWiki

Jump to: navigation, search

"Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN abandoned the practice."Sun FORTRAN Reference Manual

General

  • If you comment out a piece of code, put a clear comment about the reason to do it. Otherwise is not clear why something is commented.
  • Always use BLAS if a sentence is suitable. Don't use BLAS if a vectorial expression or a single loop has to be replaced by several blas calls.

Fortran

  • Indentation: 2 blank spaces (not tabs) for all structures.
  • Avoid one letter variable names (use ii instead of i).
  • Lower case for variables and subroutine names.
  • Upper case for preprocessor macros and constants (parameters).
  • Always declare the intent of dummy arguments.
  • All modules must be declared private and implicit none.
  • Always give the explicit name for optional arguments.
  • If it is possible and doesn't degrade performance, declare types as private and define access functions.
  • Insert calls to push_sub() and pop_sub() at beginning and end of subroutines and functions (see Emacs helpers for some Elisp to do this automatically), except in functions that are critical for performance.
  • Variables must be initialized to zero if required, do not rely on the compiler for this.
  • Declare interfaces for all external functions.
  • Do not use the ' character in comments, this confuses the C preprocessor.
  • Do not declare variables as pointer unless is necessary.

C

  • C code must be ansi compliant (ANSI ISO C90), among other things this means:
    • Variables must be defined at the begining of the block.
    • Only /* */ comments.
    • You can use the inline and restrict modifiers, autoconf handles this in case is not supported by the compiler.
  • Declare non-modified arguments as const.

Back to Developers Manual

Personal tools