C++ Code Review: What to Check So Your Code Doesn't "Explode"

Introduction: Why C++ Code Review is Not for the Faint of Heart

C++ is a language that gives a programmer incredible power. But, as Uncle Ben from "Spider-Man" said: "With great power comes great responsibility." And if in Python you can accidentally mix int and str and only get an exception, in C++ the same mistake can lead to undefined behavior (UB), which will manifest itself a month later on the client's server at 3 AM.

C++ code review is not just a checkbox in Jira. It is your shield against segmentation faults, memory leaks, and code as slow as a snail. Many developers (especially those coming from Java or Python) think code review is about checking style and variable names. In C++, it goes much deeper. Here you need to look into the very soul of the program: memory management, RAII, const-correctness, and whether that smart pointer will shoot you in the foot.

In this article, I have compiled a real checklist for C++ code review. Arm yourself with it when you do your next code review. Let's go!

1. Memory Leaks and Resource Management (RAII)

This is the holy of holies in C++. If you see new without delete — that's a red flag. But in modern C++ (C++11 and newer), we shouldn't be writing new manually at all. Use smart pointers: std::unique_ptr, std::shared_ptr. If a developer uses raw pointers (int*) for resource ownership — that's a reason to ask a question.

Example of Bad Code (Red Flag):

void process() {\n    int* data = new int[1000];\n    // ... some code ...\n    if (error) {\n        return; // LEAK! delete not called\n    }\n    delete[] data;\n}\n

Example of Good Code (RAII):

void process() {\n    std::vector<int> data(1000);\n    // ... code ...\n    if (error) {\n        return; // All good, the vector will clean up memory itself\n    }\n}\n

What to check in a C++ code review:

\n
• Are there new/delete in the code? If yes — why? Why not std::make_unique?
\n
• Are std::unique_ptr used for exclusive ownership?
\n
• Is std::shared_ptr passed by value where a reference would suffice (this is expensive due to the atomic counter)?
\n
• Are there leaks during exceptions (exception safety)?
\n

2. Undefined Behavior (UB)

In C++, the compiler trusts the programmer. If you write nonsense, the compiler won't scold you — it will just generate code that can do anything. UB is the scourge of C++. Here's what to catch during review:

\n
• Array out-of-bounds access: arr[10] for an array of 10 elements.
\n
• Using a variable after moving from it: std::move is not magic; the moved-from object is in a valid but unspecified state.
\n
• Signed integer overflow: INT_MAX + 1 is UB! (Unlike Java, where it simply wraps around).
\n
• Dangling reference: returning a reference to a local variable.
\n

Example of UB (look for this in code review):

int& getValue() {\n    int x = 42;\n    return x; // UB! x is destroyed after exiting the function\n}\n\nvoid example() {\n    int& ref = getValue();\n    std::cout << ref; // Might print 42, or garbage, or crash\n}\n

Tip for the reviewer: if you see arithmetic with int, especially in loops or when working with sizes — check for potential overflow. It's better to use size_t for indices and std::ssize() for safe comparison.

3. Const-correctness: Make Everything Cons