Fortran Style Guide

<ul><li><a name="tex2html3" href="#SECTION00020000000000000000">Introduction</a> </li><li><a name="tex2html4" href="#SECTION00030000000000000000">Subroutines and Functions</a> </li><li><a name="tex2html5" href="#SECTION00040000000000000000">Commenting Styles</a> </li><li><a name="tex2html6" href="#SECTION00050000000000000000">DO loop format</a> </li><li><a name="tex2html7" href="#SECTION00060000000000000000">IF statement format</a> </li><li><a name="tex2html8" href="#SECTION00070000000000000000">General</a> </li><li><a name="tex2html9" href="#SECTION00080000000000000000">CM CMGUI Link Code</a> </li></ul>

<h1><a name="SECTION00020000000000000000"> Introduction</a> </h1>

The purpose of this document is to outline the programming style all CMISS programmers should adopt when adding to/extending or otherwise altering Fortran code in CMISS.

<h1><a name="SECTION00030000000000000000"> Subroutines and Functions</a> </h1>

The following is a sample subroutine (blank lines are to be included as well)

<pre> SUBROUTINE SAMPLE(integer variable names in alphabetic order, real variable names in alphabetic order, complex variable names in alphabetic order, character variable names in alphabetic order, logical variable names in alphabetic order, ERROR,*) C#### Subroutine: SAMPLE C### Description: C### Provides an example for programmers to copy when creating new C### subroutines. A description of the function of the subroutine C### should be here. C**** Created by <name> YYYY-MM-DD IMPLICIT NONE CHARACTER*(*) ROUTINENAME PARAMETER(ROUTINENAME='SAMPLE') INCLUDE 'cmiss$reference:aaaa00.cmn' ! Parameter List INTEGER integer variables in parameter list in alphabetic order REAL*8 real*8 variables in parameter list in alphabetic order COMPLEX complex variables in parameter list in alphabetic order CHARACTER character variables in parameter list in alphabetic order LOGICAL logical variables in parameter list in alphabetic order CHARACTER ERROR*(*) ! Local variables INTEGER local integer variables in alphabetic order REAL*8 local real*8 variables in alphabetic order COMPLEX local complex variables in alphabetic order CHARACTER local character variables in alphabetic order LOGICAL local logical variables in alphabetic order ! Functions INTEGER integer functions in alphabetic order REAL*8 real*8 functions in alphabetic order CHARACTER character functions in alphabetic order LOGICAL logical functions in alphabetic order CALL ENTERS(ROUTINENAME,*9999) C Main body of code. NOTE: Variables that are not used should not be C passed or declared as local. IF(error condition) THEN CALL FLAG_ERROR(0,'error condition not satisfied') GOTO 9999 ENDIF C More main body of code. There should be no tabs in the code. C If you are not using emacs then you may need to customize your editor C to prevent it indenting with tabs. CALL EXITS(ROUTINENAME) RETURN 9999 CALL ERRORIN(ROUTINENAME) CALL EXITS(ROUTINENAME) RETURN 1 END </pre>

Functions have a similar form with no ENTERS or EXITS calls: <pre> REAL*8 FUNCTION TEST(integer, real*8, complex, character, logical) C#### Function: CALC_NUM_SITE C### Type: REAL*8 C### Description: C### Returns the length of a piece of string. IMPLICIT NONE Variable declarations as for subroutines code TEST=RP-DF RETURN END </pre>

Note: All routines should have a 1 line description at the top of the module. e.g. <pre>C### Routine: TEST (fn) solves NP-complete problems in linear time C### Routine: SAMPLE solves NP-complete problems in constant time </pre>

The routines in modules should be separated into groups of block data units, then functions, then subroutines, sorted alphabetically within each group.

<h1><a name="SECTION00040000000000000000"> Commenting Styles</a> </h1> <pre>C*** For any comment that should stand out C??? For any queries C!!! For caution remarks. C!!! e.g. suspected bugs, temporary additions, quick hacks (!) C PJH 2002-05-29: For major alterations, code deletions IF(INLINE_COMMENT) THEN ! Inline comments ENDIF C For all other comments </pre>

These last two styles are flexible. In general, use '!' for non-intrusive comments and 'C' for more visual comments.

When major new variables are introduced the commenting style described in <a name="tex2html1" href="http://www.esc.auckland.ac.nz/Groups/Bioengineering/CMISS/help/programmer/comment-spec.html">documentation comment

format</a>

should be used.

All IF statements using codes or flags should be commented. e.g. <pre> IF(KTYP26.EQ.1) THEN ! Optimising wrt to material parameters C Statements... ENDIF </pre>

<h1><a name="SECTION00050000000000000000"> DO loop format</a> </h1> Use lower case for loop variables. e.g. <pre> DO ng=1,NGT(nb) A(ng)=B(ng) ENDDO !ng </pre>

Indicate close of loops with a comment (as above).

DO loop counters should be INTEGER and not REAL or DOUBLE PRECISION variables.

<h1><a name="SECTION00060000000000000000"> IF statement format</a> </h1> <pre> IF(...) THEN ELSE IF(...) THEN ENDIF !... </pre>

Indicate close of conditionals with a comment (as above).

<h1><a name="SECTION00070000000000000000"> General</a> </h1> <ul><li>All output should be less than 90 columns. </li><li>All indentation is by 2 spaces, not tabs. If you are using nedit as an editor you will need to edit the preferences so that it does not use tabs for indentation. </li><li>All code lies within 72 columns, and all comments where possible. </li><li>To indicate continuation of the previous line, use `&' as the character

in the 6th column. The code on continued lines should be indented by 2 spaces more than the code on the first line of the statement.

</li><li>All real constants should be explicitly stated as double precision.: Use a small letter `d'. e.g. 0.0d0 not 0. or 0.0
</li><li>All numerical constants or tolerances generally used should be in: symbolic form and defined in a common block, initialized in a block data unit. e.g.

<pre> A=2.0d0*PI IF(DABS(SUM).LT.ZERO_TOL) SUM=0.0d0 </pre> </li><li>String literals should not span lines. If a long string is required use the concatenation operator to join strings across lines. e.g. <pre> LONG_STRING='If this string was one literal, spread across two '// & 'lines, it would be unclear how many spaces were in the middle.' IF(DABS(SUM).LT.ZERO_TOL) SUM=0.0d0 </pre> </li><li>Multiple local variables should be like nn1,nn2 not n1n,n2n. </li><li>Initialization of common block variables must NOT be done using DATA statements in procedures or functions; use a block data unit. </li><li>When declaring an array, the dimensions should not be split across more than one line. </li></ul>

<h1><a name="SECTION00080000000000000000"> CM CMGUI Link Code</a> </h1> In order to keep the link between CM and CMGUI up to date, it is necessary to include ``house-keeping'' code inside CM. Currently, this is only implemented for nodes, although in the future it can be expected to be extended to include elements, basis functions, etc. When creating or destroying nodes, it is necessary to call either <tt>NODE_CREATE</tt> or <tt>NODE_DESTROY</tt>. These subroutines take only the node number (i.e. <tt>np</tt>) of the particular node. <pre> CALL NODE_CREATE(np,ERROR,*9999) </pre> or <pre> CALL NODE_DESTROY(np,ERROR,*9999) </pre>

Whenever you write (or modify) code that modifies nodes (i.e. nodal values or the actual fields that are stored at the node), then it is necessary to add a call to the subroutine <tt>NODE_CHANGE</tt>. This takes the node number <tt>np</tt> to be changed, and whether or not the structure of the node changes. i.e. <pre> CALL NODE_CHANGE(np,.TRUE.,ERROR,*9999) </pre><name></name>

Personal tools

Fortran Style Guide