Page History

This document was drawn from C++ General Recommendations on the Trac/Wiki. There have been some significant re-formatting for Confluence. The content on this page should be verified before the Trac/Wiki pages are removed.

General Recommendations

2-1. Remember, we are writing code for humans to read, not computers.

At some point, someone unfamiliar with your code (often a future you) will have to examine it, typically to fix a bug or upgrade it. These tasks are made much simpler if the code is easily readable and well-documented.

2-2. We are writing C++11/14 with some restrictions.

  The official policy on the use of C++11 features is at Policy on use of C++11/14 language features.

2-3.Some rules MAY be violated under certain circumstances.

Refer to the section Deviating from the DM Style in DM's Policy on Coding Style for guidance on when you may deviate from a guideline.

2-4. Object orientation SHOULD be used in your programs

• Do not just code C style in C++. Make a real class for any behavior on a data structure, do not make a struct for the data and separate functions to operate on it. Structs are appropriate only for cases needing very lightweight data structure and no behavior.

• Avoid overly complex inheritance hierarchies, more than 3 levels should be a warning sign (except in Frameworks).

• Use inheritance to specialize behavior for the same or similar data, use templates to specialize data for the same behavior.

• Avoid multiple inheritance, and only use when it is for completely distinct/disjoint considerations (such as application role versus persistence container type).

• You may overload member functions but try to do so only where required (virtual functions) or you need to vary the parameter list.

• Keep functions short and with a single purpose.

The process combines UML modeling and C++ programming, they are integrated and reinforce each other. This process integration is documented in LSST Prototyping Environment.