Coding Style Document

General Style

• You SHOULD use the Object Oriented features of Fotran as much as possible. If you are constantly casting things or doing IsKindOf calls on objects, then your design is probably wrong.
• You should protect your data. All member variables SHOULD be protected and only accessible (where apropriate) via methods. Furthermore, you SHOULD avoid exposing details of implementation that might change. Supply a feature set of methods that could, if necessary, have an entirely different implementation or platform
• When allocating memory on the heap you SHOULD make sure it is explicit in the object design where objects need to be deleted and whose responsibility it is. Use try/catch blocks where you are allocating memory on the heap and clean up after exceptions.
• You SHOULD program defensively. Anticipate breakages. Always test your code, especially with boundary conditions. Consider writing tests before you write your code (the XP way).
• You SHOULD program defensively. Anticipate breakages. Always test your code, especially with boundary conditions. Consider writing tests before you write your code (the XP way).

Files Organisation

• You SHOULD use one file per module where practical. Small helper modules that are 'local' to a major module can be incorporated in the same file but you should use separate files if the code gets too large.
• You SHOULD name source files after the module name they implement and omit the leading 'm_'. For example, the module m_Widget will reside in the file Widget.f90

Hungarian notation

• Some Hungarian notation to indicate the type of a variable in its name may be used. Names start with one or more lower-case letters to indicate the type of variable. For example:
  1. iCount integer
  2. lCompleted logical
  3. cNameOfTag character
  4. pThing pointer (can be combined with the others to indicate a pointer to a specific type).
  5. ppThing pointer to a pointer.
• Otherwise, you SHOULD use studly caps to separate words, not underscores. The first letter may be in caps. If type identifier is present the letter after SHOULD be in caps.

Global variables and constants

• Constants SHOULD be all implemented in a separate module (eg. m_Constants) and SHOULD be prefixed by k_ (eg. k_pi),
• You SHOULD NOT use global variables (with obvious exceptions, like the sole instance of your primary object). They are a source of bugs, and can usually be avoided. If you do need to use global variables, you SHOULD prefix their names with 'g_' (for instance, g_iTotalHits).

Module comments

• Each module SHOULD have a similar block comment preceding with Author, Date, and description. The description should give any specific instantiation or initialisation notes, and where possible, usage examples. You SHOULD use doxygen style comments.

Module naming convention

• Module names SHOULD start with 'm_' and use studly caps to break up words. Use descriptive module names like m_ReadData or m_SlaterKoster
• You SHOULD NOT use other underscores than "m_" in module names.

Variables

• Variables of a module or subprograme SHOULD use the conventions above. For example:
  1. integer NoOfOrbitals
  2. real ElectronicEntropy
• There is no specific convention for local variables but the name SHOULD be descriptive.
• You SHOULD always initialise variables to a known initial value.

Subprograms naming

• Subprograms SHOULD always start with a capital and SHOULD use capitals to brake words. For example, if you have subprograms to get or set properties of your modules, use GetSomeProperty and SetSomeProperty. For logical properties, IsSomeState is a better choice than Get.

Data types naming

• User defined data types SHOULD use capitals to brake words and SHOULD use 'Type' as a suffix.(eg OrbitalsType)

Statements

• Each line SHOULD contain at most one statement do not use multi-statement lines. An if statement SHOULD always have a then.Eg.
  if (SomeLogicalExpression) then
  call PrintMe()
  endif
  rather than:
  if (SomeLogicalExpression) call PrintMe()
  
• When using select case statements, you SHOULD explicitly comment any deliberate fall-through behaviour (where you deliberate omit the break from the end of a case clause).

Comments

• You SHOULD use exclamation sign (!) for comments. You SHOULD put comments on lines starting in the 0 column and avoid long lines. Use comments to explain why an action/procedure is required. What you are doing SHOULD be obvious from the code itself.
• For commenting modules/subprograms/types definitions, you SHOULD use doxygen block comments.
• A comment should preferably look like this

   \brief short description of the action
   \details (optional) more details and notes
   \author The Name
   \date creation date (optional) time
   \remarks (optional) extra comments
   

White space and indentation

• You SHOULD use spaces rather than tabs (2 spaces for a tab stops are recommended). More editors will have options to assist with this.
• Blank lines SHOULD never appear more than one.
• You SHOULD avoid lines longer than 132 characters.
• You SHOULD break up long lists of parameters, indenting the broken lines to the right of the start of the first line. Call Procedure(BigName, AnotherParameter, GoshThisIsLong)
  becomes:
  Call Procedure(BigName,
  AnotherParameter,
  GoshThisIsLong);
• You SHOULD use 2 spaces to indent the code. The end of a block should be on the same column with the start block. The content of a block should be indented 2 spase with respect to the belonging code. Eg.

   do i=1,n
     if (lCondition) then
       a=3
     endif
   enddo
   a=5