C++ is a powerful language — but it’s also a highly complex one, and that

complexity makes it highly vulnerable to misinterpretation and overcomplication.

It’s easy to miss bugs in C++ that would stand out like a sore thumb in simpler
languages — and when the bugs do appear in production it might be harder to locate
them compared to other languages.

In short, C++ needs to be handled with care — and reviewed with an eagle eye.

This blog is divided into two parts. In part one, we’ll discuss more general
aspects of code review. In part two, we’ll dive into specific C++ code review
topics and build a checklist for C++ code reviews.

Why is C++ code review so important?

No matter what language you’re coding in, it’s always difficult to see the bugs and
errors in your own code, either because you wrote it to begin with, or because
you’re simply unaware that what you’re doing might be wrong. Having someone review
our code is a great way around this issue.

In addition, the mere discussion of code between two people or more raises new
questions and helps in pinpointing the important issues.

The above is true for any programming language you use, but the complexity of C++
makes it even more critical, requiring at least one extra set of eyes to review
your code, is essential.

What comes before code review?

There are two things that you need before submitting your code for review.

The first is passing a static code analysis and being able to explain any warnings
you find that could be false positives or shouldn’t be handled for any reason.
There are great static code analysis tools out there – both open source and
commercial – and there is no reason not to use them. We assume of course that you
do not leave any compiler warnings, but in the rare cases where you have a really
good reason to ignore a compiler warning, it should of course also have good
explanation prepared ahead (e.g. as a comment above a pragma declaration,
instructing the compiler to ignore the warning).

The second thing you need is to actually test your code. You’ll want to run unit
tests that generate enough coverage of your code, preferably including errors and
edge cases. Without testing there is no sense in conducting a code review, as you
can’t tell whether your code actually works. Moreover, one of the items to be
reviewed in a code review are the tests. If you add tests after code review, make
sure that changes made in the code, following test failures, do not escape code
review.

Both static code analysis and good unit tests can reduce issues from propagating
into the code review and let you fix things beforehand, but they can’t catch every
single issue.

For instance, if you got the requirements wrong from the start, neither great tests
nor static analysis will reveal the issues there. On the other hand, code review
considers the requirements and helps you map them to the code and tested scenarios.
This lets you find inconsistencies between the requirements and the actual code.

In a recent survey by SmartBear, 24% of respondents pointed at code review as the

number-one way a company can improve the quality of its code. With unit testing
being second runner and static code analysis dragging behind. It’s not that unit
testing and static code analysis are not important, it might be that respondents
were seeing code review as something that tend to be sometimes neglected, or not
well performed. But it is clear that unit tests and static code analysis do not
replace the need for code review

The main things to look for in code review

The ultimate goal of code review is to locate points where code is faulty or can be
improved. This includes looking for:

Whether the code meets the requirements

Whether code fits coding conventions and guidelines
Logical errors, bug-prone code, potential bugs and actual bugs including
concurrency issues
Design flaws, inefficiencies, and future readiness
Places where code can be simplified
Whether we have good unit tests that would also pick up future bugs
Before elaborating on the above list, let’s look at the technicalities of code
review and the ways to perform code review.

Types of code review

There are several ways to conduct code review:

The classical code review meeting

The major stakeholders meet with the developer(s) who wrote the code in question.
The size of the group depends on the importance and complexity of the reviewed
code. The review may include developers from other teams, system engineers, product
management and testing engineers. Some see it as a waste of time to include non-
developers in a code review, but if the session is focused on the way complicated
requirements were implemented, they might have valuable insights. It may also
simply include the developer and a single reviewer.

Issues raised during the code review can be fixed immediately if they’re “quick
wins” (e.g., renaming variables and functions or adding short comments). Other
issues should be documented to be handled later. At the end of the code review,
there should be a decision made as to whether the code can be integrated (after
fixing minor comments if any) or should be presented again for another review.

It is to be noted that the meeting described can be physical or virtual.

It’s common practice to have someone on
it, with the coder only being called on
that the code is generally readable. On
have the coder themselves present their
which fits your team better.
the team who didn’t write the code present
if something is unclear. This helps ensure
the other hand, it can be more efficient to
code. It’s worth trying both ways to see

Pros:

A discussion is a great tool to raise up questions that wouldn’t be raised

otherwise.
The code implementer can respond to comments, resolving some of them on the spot,
and creating a fruitful discussion for others.
Cons:

Hard to go into questions that require in-depth investigation (which would probably
go off-line and wouldn’t be closed in the same meeting).
Time-consuming and less efficient, especially if performed in a large group – not
every discussion is relevant for all participants.
Need to find a suitable timeslot that fits all stakeholders.
Offline code review
A developer completes their changes to the code and asks for a code review via the
source control, as a pull