C++ code you won't be ashamed to show colleagues: code style and conventions

When "it works" isn't the main thing

Imagine a situation: you open someone else's pull request in C++. The code compiles, tests pass, the logic is correct. But you spend 40 minutes trying to understand what's going on. Variables are named a, b, ptr2, indentation jumps from 2 to 8 spaces, and one file mixes snake_case and camelCase. Sound familiar?

In solo development, such chaos is still survivable. But as soon as a second, third, or tenth developer joins the project, the lack of a unified C++ code style turns the code into a "swamp." Everyone writes the way they're used to, and code review time grows exponentially.

In this article, we'll break down which C++ conventions actually work in a team, how to implement them without pain, and why it will save you nerves and money. Let's go!

Why code style isn't about "looking pretty," but about money

Many people think arguing about code style is a waste of time. In practice, research (for example, from Google and Microsoft) shows: code readability directly affects the number of bugs. When a developer spends less effort deciphering what's written, they make fewer mistakes during refactoring and find problems faster.

A unified C++ coding standard gives a team three key advantages:

\n
• Onboarding speed. A new member doesn't have to guess how things are written here — they just look at any file and see the pattern.
\n
• Minimum conflicts in code review. Instead of "rewrite the indentation," you discuss architecture and logic.
\n
• Automation. Formatters and linters take over the routine, freeing your brain for creativity.
\n

The good news: you don't need to reinvent the wheel. There are proven C++ best practices that adapt to any project.

Basic C++ conventions: from naming to formatting

Let's go through the key blocks that are worth fixing in a code style guide. For each point, I'll give an example of "bad" and "good."

1. Naming: snake_case vs CamelCase vs PascalCase

In C++, a hybrid approach has historically developed. The standard library uses snake_case, many companies (Google, Microsoft) also prefer it for variables and functions. For classes and structs, PascalCase is more often used.

Example of bad naming:

class datamanager {\n    int numberOfElements;\n    void ProcessData(int* ptr) { ... }\n};

Problems: class in snake_case, method in CamelCase, no context. Better like this:

class DataManager {\n    int number_of_elements_;\n    void ProcessData(int* data_ptr) { ... }\n};

What's fixed here:

\n
• Class — PascalCase.
\n
• Fields — snake_case with an underscore suffix for private members (Google style).
\n
• Method — PascalCase (or snake_case, if accepted in the team).
\n
• Parameter — snake_case with the suffix _ptr to make it immediately clear it's a pointer.
\n

Tip: choose one style for the entire project. Mixing getValue() and get_value() in one file is a sure path to confusion.

2. Formatting: spaces, braces, and line length

The most common source of arguments — where to put the opening brace: on the same line or the next? In C++, it's common to put it on the same line (K&R style), but there are variations.

Example of a consistent style:

void CalculateSum(const std::vector<int>& values) {\n    int sum = 0;\n    for (size_t i = 0; i < values.size(); ++i) {\n        sum += values[i];\n    }\n    return sum;\n}

Here everything is uniform: brace after if, fo