Versions Compared

Old Version 20

changes.mady.by.user Kian-Tat Lim

Saved on

compared with

New Version Current

changes.mady.by.user Jonathan Sick

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Info

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.

Section
Column
width400px
Panel
titleBGColor#CFECEC
borderStylesolid
titleControlled Document

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:

Jira
showSummaryfalse
serverJIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId9da94fb6-5771-303d-a785-1b6c5ab0f2d2
keyRFC-24
).

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:

To request changes to these standards, please file an RFC (ref: Discussion and Decision Making Process).

Panel
titleBGColor#CFECEC
borderStylesolid
titlePreface

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.

Column
width250px
Panel
bgColor#F7FFFF
titleBGColor#CFECEC
borderStylesolid
titleContents

 

Table of Contents
maxLevel3
indent24px

...

skip-headingsh4
start-numbering-with1
start-numbering-ath2

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.

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.

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.

General Recommendations

Naming Conventions

General Naming Conventions

Specific Naming Conventions

Files

Source Files

Include Files and Include Statements

Statements

Types

Variables

Loops

Conditionals

Methods and Functions

Constructors and Destructors

Miscellaneous

Layout and Comments

Layout

White Space

Comments

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.

References

...

...

...

...

...

 

...

...

...