User Tools

Site Tools


coding-conventions

This is an old revision of the document!


Naming conventions

The names of classes, attributes, services, variables, and functions in a program serve as comments of a sort. So don't choose terse names–instead, look for names that give useful information about the meaning of the variable or function. In a OOFEM program, names should be English, like other comments.

Local variable names can be shorter, because they are used only within one context, where (presumably) comments explain their purpose.

Try to limit your use of abbreviations in symbol names. It is ok to make a few abbreviations, explain what they mean, and then use them frequently, but don't use lots of obscure abbreviations.

Please use capital letters to separate words in a name. Stick to lower case; reserve upper case for macros, and for name-prefixes that follow a uniform convention. The function or service name should always begin with lovercase letter, the first uppercase letter in function name indicates, that function is returning newly allocated pointer, which has to be dealocated. For example, you should use names like ignoreSpaceChangeFlag;

When you want to define names with constant integer values, use enum rather than `\#define'. GDB knows about enumeration constants.

Use descriptive file names. The class declarations should be placed in *.h files and class implementation in corresponding *.C files. For each class, create a separate files.

Parameters and return values

The preferred argument passing method for objects is by reference. Try to avoid returning pointers to arrays or matrices (or generally to any component), since it is not clear, whether to dealocate the returned pointer or not. The most preferred way is to create local variable of vector or matrix type, pass it (using reference) to called function. The calling function is responsible to properly resize the (output) parameter and set values accordingly. The point is, that destructors are called for local variables automatically by compiler, so there is no possibility for memory leaks and the local variable can be reused for multiple calls to target function (inside loop) and therefore there is no need for repeating memory allocation and deallocation.

Using comments to document the code

OOFEM uses DOC++ documentation system to automatically generate the reference manual directly from the OOFEM header files. By placing comments in a few strategic places a complete reference manual, including graphics, can be generated. You will typically want to do so for your header files only.

In general, a special comments should be added straigh before each function, variable, class, define, etc. you wish to document. The simplest way is to add a simple DOC++ comment with a short documentation string for the entry, e.g.:

/// Array storing nodal coordinates.
FloatArray coordinates;

If you intend to write more than one line of documentation, succeed this line with a comment like / …. */ and put the long documentation text in place of ``…''. For example: /

  • Triplet defining the local coordinate system in node.
  • Value at position (i,j) represents angle between e'(i) and e(j),
  • where e' is base vector of local coordinate system and e is
  • base vector of global c.s.
  • /

FloatMatrix localCoordinateSystem;

DOC++ automatically imposes a hierarchical stucture to the manual entries for classes, structs, unions, enums and interfaces, in that it organizes members of such as sub-entries. If you need to group manual entries, you may do so with the construction:

/**@name <name for the group>
 *  <documentation for the group>
 */
//@{
  <other manual entries>
//@}

This will create an entry with the specified name, that contains all <other manual entries> as sub entries. Note, however, that class members are automatically set as sub entries of the class's manual entry.

To document a function or a method of a class, describe the working and usage of the member function, as well as the individual parameters and return values. For example:

 /**
  * Class implementing node in finite element mesh. Node posses degrees of freedom.
  * Node is atribute of few elements and it is managed by domain.
  * Node manages its positon in space, and optional local coordinate system.
  * By default, global coordinate system is assumed in each node.
  */
  class Node : public DofManager {
 

   /** Computes the load vector of receiver in given time.
     *  @param answer load vector.
     *  @param stepN time step when answer is computed.
     *  @param mode determines response mode.
     */
    virtual void         computeLoadVectorAt(FloatArray &answer, TimeStep *stepN, ValueModeType mode);
  }

Source file layout

Each source file, header or implementation file starts with a Subversion identification line and an author line, e.g.:

/* $Id$ */

Header file layout

Each header file has the following layout:

  • Subversion identification line
  • Copyright notice
  • Inclusion protection macro
  • Headers file includes
  • Forward declarations
  • Actual class definition with DOC++ comments

For a typical example see element.h.

Each implementation file has the following layout:

  • Subversion identification line
  • Copyright notice
  • Header file includes
  • Actual method implementation

For a typical example see element.C

Indentation & formatting

Coding style is very personal and we don't want to force our views on anybody. But for any contributions to the OOFEM system that we have to maintain we would like you to follow our coding style and common formatting. We ask all contributors to use Uncrustify (Source Code Beautifier) to reformat the code according to our defaults. We provide the uncrustify config file (located in top oofem directory). To run uncrustify on a selected file, use

uncrustify -c oofem_dir/uncrustify.cfg --replace mysource.C
coding-conventions.1245238546.txt.gz · Last modified: 2009/06/17 13:35 by bp