Skip to content

Coding Conventions Style Guide

Michael Beyeler edited this page Mar 5, 2017 · 1 revision
  • When in doubt, adhere to the Google C++ Style Guide.

  • Use tabs for indentation, worth 4 spaces.

  • Maximum line width is 120 characters.

  • Left-Hand side curly braces go at the end of your class/function/main definitions/prototypes (on the same line). Example: int myFunction(float myFloat) { // <--- same line

  • The same is true for conditional and looping statements:

if (condition) {
    // code
}
for (int i=0; i<endLoop; i++) {
    // code
}

If the conditional statement cannot fit on a single line, put the left-hand side curly brace on the next line, like so:

if (conditionA && condition B &&
    condition C)
{
    // code
}

Otherwise the conditional statement conditionC will be aligned with //code, which looks confusing.

  • Variables, functions, class methods, class members all use camelCase (e.g. myVariableName; not MyVariableName, not my_variable_name, and certainly not my_variableName), starting with a lower-case letter. Class names use UpperCamelCase (e.g., SpikeMonitorCore).

  • snn.h has suggested abbreviations for common variable names (number = n, neuron = neur, etc.). So an appropriate variable name for the number of synapses would be nSynapses (not numSynapses), whereas an appropriate name for a neuron ID would be neurId (not nid or nId).

  • Doxygen-style (\brief,\param[in], \return) comments should be included in the function/method prototypes of the classes (carlsim.h, snn.h, etc.). See Working with Doxygen.

  • All class member variables have the underscore suffix (example: var1_). This is not yet consistent across the CARLsim code but it will be eventually.

  • Avoid using unsigned ints in place of ints to save space. They often do more harm than good because they allow arithmetic underflow.

  • Move unsafe/risky operations out of the constructor and the destructor because these functions do not throw errors correctly.

  • Pass function arguments as const whenever possible/meaningful (that is for pointers, references, strings, etc.; not necessarily for primitive types such as ints passed by value), to ensure the function doesn't change the arguments it is not supposed to change.

  • Significant additions to the code-base should include test cases. Please use google-test.