Revised 2006-09-05 DMB

Return to the Index

# Coding Standards

This document describes the coding standards that should be followed when developing within Avida.

## Coding Style Guidelines

### Indentation

- All source code indentation should be spaces. This includes C++, Python, and HTML.
- The size of a single indentation is 2 spaces.

### Braces

#### Function Definitions

Open and close braces should each be on their own line. Do not place the open brace on the same line as the function signature. The only exception to this rule is single line class methods, in which both braces are allowed to be on the same line as the code (but only in pairs). Examples:

##### Right:

    void cFoo::Method()
    {
      // code goes here
    }

    // ... in a class
    inline void Method() { ; }

    inline void Method()
    { // longer code in here }

##### Wrong:

    void cFoo::Method() {
      // code goes here
    }

    // ... in a class
    inline void Method() {
      ; }

#### For, While, Do Loops and Switch Statements

The open brace should go on the same line as the control structure, the close brace on its own line. Examples:

##### Right:

    while (foo) {
      // code goes here
    }

##### Wrong:

    while (foo)
    {
    }

#### If/Else Statements

The same formatting rules as for/while/etc., but if there is an else clause the close brace should go on the same line as the else statement. Single line if else statements should not get braces, unless they accompany a multi-line statement. Examples:

##### Right:

    if (foo) {
      DoSomething();
      DoAnotherSomething();
    } else {
      DoADifferentSomthing();
    }

    if (!foo) CallAFunction();
    else CallBFunction();

##### Wrong:

    if (foo)
    {
      DoSomething();
      DoAnotherSomething();
    } else
      DoADifferentSomthing();

    if (!foo) {
      CallAFunction();
    }
    else CallBFunction();

### Parentheses

#### Function Declarations and Calls

Do not use any space between the name and the open parenthesis, inside the parentheses, or before commas that separate arguments. A single space should follow commas that separate arguments. Examples:

##### Right:

    void cFoo::Method(int arg1, double arg2);
    int aFunction();

##### Wrong:

    void cFoo::Method( int arg1 , double arg2 );
    void cFoo::Method (int arg1, double arg2);
    int Function ( );

#### Control Structures

Control structures such as if, for, while, do, and switch statements use a single space before the open parenthesis, but spaces inside them.

### Other Punctation

- Pointer and reference types should be written with NO space between the type name and the * or &.

### Include Guards and Statements

- All header files must use include guards, where the name of the guard is exactly the filename with the period replaced with an underscore. For example, `cPopulation.h` is guarded by:

      #ifndef cPopulation_h
      #define cPopulation_h

      // Code goes here

      #endif

- Include statements in header files (`.h`) must check for previously defined include guards. Example:

      #ifndef cPopulation_h
      #include cPopulation_h
      #endif

- Include statements in implementation files (`.cc`) must not check include guards.

## Naming Conventions

- Variable names should be all lowercase. Multi-word variables should have the words separated by underscores ('_'). Examples:

      i
      position
      this_is_my_var

- Class instance member variables should have the same format as regular variables, but must be prefixed with 'm_'. Examples:

      m_type
      m_lexeme
      m_my_component

- All functions and public struct/class methods should begin with a capital letter followed by lowercase. Additional words should be signified by capital letters. Underscores should only be used to indicate a category of functions. Examples:

      Sort()
      ThisIsMyFunction()
      cHardwareCPU::SingleProcess()

- Private and protected struct/class support methods should begin with a lowercase letter. Additional words should be signified by capital letters. Underscores should only be used to indicate a category of functions. Examples:

      cHardwareBase::doSlipMutation()
      cParser::parseCodeBlock()

- All class names should begin with a lowercase 'c', followed by capital letters leading each word (similar to functions). Templates have the same pattern, but beginning with a 't', and enumeration types begin with an 'e'. Lastly, structs should begin with a 's'. Examples:

      cGenome
      tArray
      eHeadTypes
      sSomeData

- All constant values (even as listed in enumerations) should be in all capital letters, with words separated by underscores. Examples:

      NUM_REGISTERS
      MAX_STRING_LENGTH

- All filenames should be the same as the class defined within that file. Header files should use `.h`; implementation files should use `.cc`. Examples:

      cGenome.h
      tArray.h
      cPopulation.cc

- Generally, there should only be one class defined in each header/source file pair. Implementation helper classes should be defined as internal class members.

## Class Dependency Guidelines

Some groupings of classes should maintain important limitations with respect to class dependency.

### Tools Classes

All classes developed as general utility classes should be placed within the `source/tools` directory. These classes should have no dependencies that extend outside of this directory.

### STL Usage

Usage of the Standard Template Library should be very limited. A number of these templates have unspecified orderings that can vary across platforms, affecting consistency. Where possible, it is greatly preferred to use the local tools classes.

Return to the Index