This document was drawn from C++ Code Standards on the Trac/Wiki. There have been some light edits (including some re-formatting for Confluence). The content on this page should be verified before the Trac/Wiki pages are removed.
This is the DM C++ Coding Standard. Changes to this document and its sub-documents are to be made only with the approval of the System Architect (ref: RFC-24 - Getting issue details... STATUS ).
Prior revisions are available via the Page History in Confluence, but the most recent version at any point in time is considered authoritative.
Older revisions are available on the Trac/Wiki:
- Revision 1.5 (2009-Feb-18)
To request changes to these standards, please file an RFC (ref: Discussion and Decision Making Process).
The communal nature of creating project software necessitates simplicity and elegance in the crafting of code. Since a piece of code may be a collaboration, as much as any paper, without readability and comprehensibility the result of the collaboration may not preserve integrity of design intent. Without simplicity, it might not be possible to make a judgment of that integrity.
Preserving integrity of design intent is important. The creation of a piece of software is an exercise in developing a consistent set of descriptions (requirements, design, code, tests, manuals) that preserve and manage the evolution of the intent of that software throughout its lifetime. This gains more importance as the key form of these descriptions is an operational (imperative) form, which will decide how a system will react to specified (an, in some cases, unexpected) external stimuli.
This document is strongly based on (verily, virtually identical to) the CARMA[9] C++ Coding Standards which, in turn, was strongly based on Geosoft[6] and ALMA[7] C++ Coding Standards. We have taken the CARMA HTML document and changed it in places to match LSST's needs. CARMA, Geosoft and ALMA retain their respective copyrights where appropriate.
1. Introduction
This document lists C++ coding recommendations common in the C++ development community. The recommendations are based on established standards collected from a number of sources, individual experience, local requirements/needs, as well as suggestions given in References (1 - 4).
While a given development environment (IDE) can improve the readability of code by access visibility, color coding, automatic formatting and so on, the programmer should never rely on such features. Source code should always be considered larger than the IDE it is developed within and should be written in a way that maximizes its readability independent of any IDE.
Refer to DM's Policy on Coding Style for the guiding principles regarding the stringency levels and under what circumstances you may deviate from a guideline.
1.1. Layout of the Recommendations
The recommendations are grouped by topic and each recommendation is numbered to make it easier to refer to during reviews.
Layout of the recommendations is as follows:
x.y Guideline
Short description
Motivation, background and additional information.
The motivation section is important. Coding standards and guidelines tend to start "religious wars", and it is important to state the background for the recommendation.
1.2. Recommendation Importance
In the guideline sections, the terms REQUIRED, MUST, SHOULD, amongst others, have special meaning. Refer to the stringency levels in DM's policy on Coding Style for their definitions.
DM uses the spirit of the IETF organization's RFC 2199 Reference(10) definitions.
2. General Recommendations
3. Naming Conventions
3.1. General Naming Conventions
3.2. Specific Naming Conventions
4. Files
4.1. Source Files
4.2. Include Files and Include Statements
5. Statements
5.1. Types
5.2. Variables
5.3. Loops
5.4. Conditionals
5.5. Methods and Functions
5.6. Constructors and Destructors
5.7. Miscellaneous
6. Layout and Comments
6.1. Layout
6.2. White Space
6.3. Comments
7. Legacy Code
7-1. All legacy code SHOULD have an interface definition specification that follows these rules.
This rule is primarily in the case of writing wrapper classes for legacy code. While it is not expected that we will bring the guts of all legacy code in line with the specifications in this document, it is important that public interfaces follow the rules of new code.
8. References
[1] McConnell, Steve. Code Complete, 2nd Edition, (Redmond, WA: Microsoft Press), 2004. See http://www.stevemcconnell.com/cc.htm.
[2] Henricson, M., & Nyquist, E. Programming in C++, Rules and Recommendations, (Alvsjo, Sweden: Ellemtel Telecommmunication Systems Laboratories), 1992. Available on-line at:
[3] Eckel, Bruce. Thinking in C++, (2nd Ed; Englewood Cliffs, NJ: Prentice Hall), 2000. Available on-line at:
[4] Hoff, Todd. C++ Coding Standard, 2008. Available on-line at:
[5] Doxygen documentation system. Available on-line at:
[6] Geosoft C++ Programming Style Guide. Available on-line at:
[7] Bridger, Alan, Brooks, M., & Pisano, Jim. C++ Coding Standards, Revision 3, ALMA Computing Memo 0009 (Atacama Large Millimeter Array), 2001. Available on-line at:
- https://science.nrao.edu/facilities/alma/aboutALMA/Technology/ALMA_Computing_Memo_Series/0009/2001-06-06.pdf
[8] Kernighan, B. & Plauger, P. J. The Elements of Programming Style, 2nd Edition, (New York: McGraw-Hill) 1978.
[9] Pound, M. W., Amarnath, N.S., & Teuben, P.J. CARMA C++ Programming Style Guidelines.
[10] Bradner, Scott. IETF RFC 2119, . Available on-line at: