C++ Coding Style Guide

Introduction

As every C++ programmer knows, the language offers a lot of powerful features, but with that power comes additional complexity, making code more prone to bugs and harder to read and maintain.

The goal of this guide is to address these challenges by laying out clear dos and don'ts for writing C++ code. These rules are intended to keep the codebase manageable while still allowing developers to use C++ effectively.

Style, often referred to as readability, covers the conventions we follow when writing C++ code. The term may be somewhat misleading, as these conventions extend far beyond source code formatting.

Note that this guide is not a C++ tutorial: we assume that the reader is already familiar with the language.

Goals of the Style Guide

Why do we have this document?

This guide has a few key goals. These goals are the foundation of the rules that follow. By explaining them up front, we hope to make the reasoning behind individual rules easier to understand. Knowing the purpose of a rule helps determine when exceptions may be appropriate and what would be required to justify changing it.

The goals of the style guide are as follows:

• Keep only rules that provide clear and measurable benefits.
• Prioritize readability and maintainability. Code is read, reviewed, and maintained far more often than it is written.
• Maintain a consistent style across the codebase. Consistency improves collaboration, supports automation, and reduces unnecessary debates.
• Prefer standard C++ features and established idioms whenever practical. Use custom or third-party solutions only when they provide a clear advantage.
• Follow widely accepted community conventions rather than personal or team preferences.
• Restrict risky or non-obvious language features to reduce the likelihood of bugs. Exceptions should be rare.
• Use complex language features only when their benefits clearly outweigh their costs and they are understood by the team.
• Prevent namespace pollution and other scalability issues that become more significant as projects grow.
• Balance style considerations against performance requirements when necessary.
• Avoid clever, surprising, or unconventional code unless it provides a meaningful benefit.
• Apply good judgment and seek feedback when in doubt.