Chapter A2
Coding Style

The flesh has been written with the following coding guidelines; all Cactus* thorns should also follow them.

A2.1 Indentation

Two spaces, no tabs.

Two spaces are enough to clearly indent, more would be a waste of space, less not really noticeable.

A2.2 Brace positioning

Each opening brace should appear on a line by itself, aligned with the preceeding statement.

Closing braces should line up with the corresponding opening brace, and should be on lines by themselves apart from the while in a

do  
{  
 
...  
 
} while(...);  

statement.

This brace positioning stategy makes it easy to run ones eye from a closing or opening brace to its matching opening or closing brace.

Braces should be used for all if and for statements.

A2.3 GRDOC

All files should start with a grdoc header, and all functions should have grdoc headers.

The file grdoc should contain a description of the contents of the file and a version with the CVS $Header$ tag.

The function grdoc should contain

Note that the ‘calledby’ field should not be filled in as this is unmaintainable.

The standard grdoc function header is of the form

 /*@@  
   @routine    Template  
   @date       Fri Oct  6 10:51:49 2000  
   @author     Tom Goodale  
   @desc  
   An example of grdoc  
   @enddesc  
   @calls     templatefunc2  
   @calledby  
   @history  
 
   @endhistory  
   @var     templatestring  
   @vdesc   string describing foobar  
   @vtype   const char *  
   @vio     in  
   @vcomment  
 
   @endvar  
 
   @returntype int *  
   @returndesc  
   0 - success  
   or the returncode of @seeroutine templatefunc2  
   @endreturndesc  
@@*/

This is the form which will be created if you use the grdoc emacs mode. The variable descriptions and the return code decription should be placed after the history so that they are close to the actual function.

After the first actual release the history should be filled in with each change.

A2.4 Header Files

Header files should not include any system header file, but should contain in the initial comment a list of system header files which are assumed to have been included before this file is included.

The body of a header should be protected against multiple inclusion by lines of the form

#ifndef _NAMEOFHEADERFILEINCAPITALS_H_  
#define _NAMEOFHEADERFILEINCAPITALS_H_ 1  
 
...body of header file...  
 
#endif /* _NAMEOFHEADERFILEINCAPITALS_H_ */  

Function prototypes in header files should be protected against C++ linkage by

#ifdef __cplusplus  
extern "C"  
{  
#endif  
 
...prototypes...  
 
#ifdef __cplusplus  
}  
#endif

The Cactus header files (cctk_<name>) should only include information relevant for thorn programmers.

There is a template file in the doc/MaintGuide directory.

A2.5 Source Files

Source files should have as their first lines after all the include files:

static const char * const rcsid = ”$Header$”;
CCTK_FILEVERSION(<source file>);

or the expanded rcs version of this. The macro CCTK_FILEVERSION is simply there to prevent compiler warnings, and <source file> should be replaced by

Globally visable functions should appear before local functions.

(NOTE: currently the schedule stuff is a good example of what I’m coming to like as a style, e.g. src/main/ScheduleInterface.c )

There is a template file in the doc/MaintGuide directory.

A2.6 Naming Conventions

All functions which may be used by thorns should have names beginning with CCTK_ and then capitalised words with no underscores.

All functions used internally by the flesh should have names beginning with CCTKi_ and then capitalised words with no underscores.

Header files to be included by thorns should have names beginning with cctk_, and followed by capitalised words with no underscores.

Structures which may be used by thorns should have names beginning with c and then capitalised words, e.g. cGroup. The exception here is structures associated with utility routines which are not Cactus specific, there the structure names should start with a t_.

Structures which are purely internal to the flesh should have names beginning with i.

All Cactus sourcefile names (except general utility files) should use capitilised words without underscores.

A2.7 Functions

All functions should have a grdoc header.

They should have a single place of return at the end of the function to make it easy to tidy up and work out what is going on.

Where possible variables should be declared at the top of the function with no initialisation, and then initialised after all variable declarations. Of course this can’t apply to static variables, ’though these should be kept to a minimum so we can make a thread-safe version of Cactus later.