Skip to content

Code Style Guide

Jump to bottom
James Haak edited this page Sep 12, 2013 · 3 revisions

Here is where we define the particular coding style to use on all SDCR projects.

  1. Naming =========

1.1 File Names

File names are to be all lower-case and have the name of the class declared in them and the namespace that class is a part of, if applicable. The exact formatting should be: namespace_class.cpp and namespace_class.h or, if the class is not a part of a namespace: class.cpp and class.h

1.2 Namespaces

Namespaces should be CamelCased.

1.3 Classes

Classes should be CamelCased.

1.4 Functions

Functions should be camelCased, and arguments should be all lower-case and under_scored.

1.5 Variables

Variables should be camelCased. Global variables, if used, should have a "g_" added to the beginning of the variable name.

1.6 Constants

Constants, if used, should be ALL_CAPITALS.

  1. Formatting =============

Follow Section 5 of ROS's style guide

The only exception being: Namespaces. The content of namespaces should receive one level of indent.

  1. Documentation/Comments ================

Comment all code that is not self-explanatory. An example of a self-explanatory line is:

timeout_timer_ = new QTimer(this);

Also, comment blocks of related code, not individual lines. The only exception to this is declarations. All declaration should be commented with either a description of the member or a Doxygen-style comment block. Doxygen-style comments are preferred when appropriate.

All documentation will be done using Doxygen. Refer to the Doxygen Guide for more to using Doxygen.

  1. Includes =========== All includes must be in the class header or similarly significant file. They must start on the first line after the header guard.

When including multiple classes from a library, explicitly include each class you use, even if one class already includes the other. For example:

#include <QVariant>
#include <QVariantList>
  1. Committing Changes ==================

Try to include only related changes in a single commit. This will help reduce problems if we must revert the repository to an older version for some reason.

Commit messages must be at least one sentence and describe what the change is. If the change affects a issue, include the issue number in the message. Be sure to surround the "Fixes" statement in brackets and include the number sign (#) before the issue number. For example:

Had to set cutelogger to compile as static for OS X to find it. [Fixes #13]
  1. Whitespace ============= Horizontal whitespace should be used as appropriate.

Vertical whitespace should be used to separate blocks of code and to make sections of code more readable.

  1. Class Layout =============== Clases members should be defined in the following order:
  • constructor/destructor
  • public functions
  • public slots
  • signals
  • protected variables
  • protected functions
  • private variables
  • private functions
Clone this wiki locally