Code Review в C++: что проверять и как давать обратную связь новичкам

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Code Review в C++: что проверять и как давать обратную связь

Code review (ревью кода) — это обязательный этап разработки, особенно в C++. Этот язык предоставляет огромную свободу, но вместе с ней приходит и ответственность. Для начинающих разработчиков процесс ревью может казаться пугающим, но на самом деле это мощный инструмент обучения. В этой статье мы разберём, на что обращать внимание при проверке C++ кода и как давать обратную связь, чтобы она была полезной, а не обидной.

1. Базовая корректность и безопасность памяти

Первое, что нужно проверить в любом C++ коде — корректность работы с памятью. C++ не имеет сборщика мусора, поэтому ошибки здесь критичны.

Что проверять:

  • Утечки памяти: Каждому new должен соответствовать delete, каждому new[] — delete[]. Лучше использовать умные указатели (std::unique_ptr, std::shared_ptr).
  • Выход за границы массивов: Использование std::vector::at() вместо оператора [] для отлова ошибок.
  • Висячие указатели: Указатели, ссылающиеся на уже освобождённую память.
  • Двойное освобождение: Повторный delete для одного блока памяти.
// Плохо: ручное управление памятью
int* arr = new int[100];
// ... работа ...
delete[] arr; // Легко забыть

// Хорошо: используем RAII
std::vector<int> arr(100);
// Память освободится автоматически

Совет для ревьюера: Если видите сырые указатели (int* ptr) или ручной new/delete — это красный флаг. Предложите использовать std::unique_ptr или контейнеры STL.

2. Использование стандартной библиотеки (STL)

C++20/23 предоставляют богатую стандартную библиотеку. Начинающие часто пишут велосипеды там, где можно использовать готовые решения.

Чек-лист:

  • Контейнеры: Вместо сырых массивов — std::vector, std::array, std::map.
  • Алгоритмы: Вместо ручных циклов — std::find, std::sort, std::copy.
  • Строки: std::string вместо char*.
  • Потоки: std::ifstream/std::ofstream вместо C-шных fopen.
// Плохо: ручной поиск
bool found = false;
for (int i = 0; i < vec.size(); ++i) {
    if (vec[i] == target) {
        found = true;
        break;
    }
}

// Хорошо: алгоритм STL
bool found = std::find(vec.begin(), vec.end(), target) != vec.end();

Как дать обратную связь: Вместо «Это неправильно», скажите: «Отличная логика! В STL есть готовая функция std::find, которая делает то же самое, но короче и безопаснее. Давай попробуем её использовать?».

3. Стиль кода, именование и константность

Читаемость кода — половина успеха. Даже идеально работающий код бесполезен, если его невозможно поддерживать.

На что обращать внимание:

  • Именование: Переменные — snake_case (по стандарту C++), классы — PascalCase. Избегайте однобуквенных имён (кроме i для счётчиков).
  • Константность: Параметры, которые не меняются, должны быть const. Методы, не изменяющие объект — const.
  • Форматирование: Единый стиль отступов (обычно 4 пробела), пробелы вокруг операторов.
  • Магические числа: Выносите их в константы (constexpr int MAX_SIZE = 100;).
// Плохо: нечитаемо
int a = 5;
for(int i=0;i<10;i++){a+=i;}

// Хорошо: понятно и константно
constexpr int LOOP_COUNT = 10;
int sum = 0;
for (int i = 0; i < LOOP_COUNT; ++i) {
    sum += i;
}

Совет: Используйте автоматические форматтеры (clang-format) и линтеры (clang-tidy). Это снимает 80% споров о стиле.

4. Как давать обратную связь: психология ревью

Code review — это не экзамен, а диалог. Ваша цель — помочь коллеге (или себе в будущем) написать лучший код.

Правила конструктивной критики:

  • Начинайте с позитива: «Отличная архитектура!», «Классное решение с использованием лямбды».
  • Используйте вопросы: «Почему здесь выбран int, а не size_t?», «Как ты думаешь, будет ли это работать для пустого списка?».
  • Предлагайте, а не приказывайте: «Можно попробовать упростить этот цикл с помощью std::accumulate».
  • Разделяйте критику и автора: Говорите о коде, а не о человеке. «В этом участке есть потенциальная утечка» вместо «Ты допустил утечку».
  • Объясняйте «почему»: Просто «исправь» — плохо. «Исправь, потому что это может привести к UB (неопределённому поведению) на некоторых компиляторах» — хорошо.
// Пример плохого комментария:
// "Это ужасно. Перепиши."

//                

Блоги

Рекомендаций по книгам