Coding standards

Indentation

2 blanks after module, subroutine, function, program (and contains)

The corresponding ‘contains’ at same indentation.

3 blanks after if, do, type

No tabs, really. Tab enthusiasts will tell you that they are great but they are a big pain if you copy paste code or want to comment code out.

Do not use “<<<<” or “>>>>” anywhere in the code

These are conflict resolution markers.

Private vs. public

Everything should be private except names explicitly declared as public

This speeds up compilation and avoids bugs and name clashes. It gives more modular and thus better code.

Write end module, end type, end function, end subroutine, end if, end do, without name

subroutine foo end subroutine instead of subroutine foo end subroutine foo

Reason: It is unnecessary and annoying when you want to rename things, you have to rename them in two places.

Also no single-word variants endmodule, endtype, endfunction, endsubroutine, endif or enddo.

Never use F77 style common blocks

They are like nuclear waste.

Don’t put several commands on one line

Hard to read and inconvenient for debugging (when you need to uncomment one of the commands): Ef=-Ef; Eff=-Eff; Effff=-Effff; Egff=-Egff

It is also inconvenient from the version control point of view: more commands on one line increase risk of conflicts during merges.

Use module-wide implicit none

Example:

module birefring

  use this
  use that

  implicit none

  ...

Never use implicit.h. After you spend a day hunting a bug created by using implicit you know why.

Do not leave commented code behind

Also if you replace a routine by a better routine, remove the less better routine.

No program-specific CPP filters

They mean that the library is not general. Program specificity has to go to the interfaces.

Use self-explaining variable names

Also never ever reuse variable names just to save a declaration.

Module naming

Modules and files containing modules should have the same name.

Also we should not let Dalton (or DIRAC) restrict our naming. We had examples where we chose a less ideal name because the better name could upset some developers of Dalton. It is our library and we can dictate naming. Name conflicts can be resolved in interfaces.