Development Coding Style Guide

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

C/C++ Dialect

• ISO Standard C++ (1998/2003)
• Do not use GCC extensions (such as multi-line strings and comments).
• No compiler warnings with explicitly supported compilers, including GCC and Clang-LLVM.

Code Formatting

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 (.h) and implementation (.cc) files must not check include guards (no #ifndef blocks). This compile time optimization is to be left for the compiler to perform.

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 capital letters leading each word (similar to functions). Examples:

  Genome
  Array
  HeadTypes
  SomeData
  

• 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:

  Genome.h
  Array.h
  Population.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.