Code Review - это проверка кода на ошибки, неточности и общий стиль программирования. Ситуация: вы разработчик. Вы отвечаете за свой фронт работы, например, за отправку данных на сервер. У команды уже есть готовый проект, вы вместе его поддерживаете и постоянно улучшаете. Новая функция не попадает сразу в проект. Вместо этого ваш код отправляется на Code Review.
Избегайте совместного использования данных, в особенности глобальных данных. Совместно используемые данные усиливают связность, что приводит к снижению сопровождаемости, а зачастую и производительности.
Идиома С++ "выделение ресурса есть инициализация" (resource acquisition is initialization - RAII) представляет собой мощный инструмент для корректной работы с ресурсами. При выделении ресурса передайте его объекту-владельцу.
Неизменяемые значения проще понимать, отслеживать и мотивировать, т.е. там, где это целесообразно, лучше использовать константы вместо переменных.
Не используйте макросы в C++ без крайней на то необходимости. C++ предоставляет богатый инструментарий, такой как шаблонные функции, автоматический вывод типов (auto, decltype
), constexpr functions
.
Избегайте использования в коде литеральных констант наподобие 42 или 3.1415926. Такие константы не самоочевидны и усложняют сопровождение кода.
Избегайте "раздувания" областей видимости. Переменных должно быть как можно меньше, а время их жизни - как можно короче.
Неинициализированные переменные - распространенный источник ошибок в программах на С и С++.
Перегружайте операторы только в случае веских на то оснований, и сохраняйте при этом их естественную семантику. Если это оказывается сложным, возможно, вы неверно используете перегрузку операторов.
Встроенные операторы &&
, ||
и ,
(запятая) трактуются компилятором специальным образом. После перегрузки они становятся обычными функциями с весьма отличной семантикой.
Небольшие классы легче писать, тестировать и использовать. Они также применимы в большем количестве ситуаций.
Сильные связи нежелательны, и их следует избегать везде, где только можно. Следует предпочитать композицию наследованию, кроме случаев, когда вы точно знаете, что делаете и какие преимущества дает наследование в вашем проекте.
Классы, предназначенные для автономного использования, подчиняются правилам проектирования, отличным от правил для базовых классов. Использование автономных классов в качестве базовых является серьезной ошибкой проектирования и его следует избегать.
Избегайте возврата дескрипторов внутренних данных, управляемых вашим классом, чтобы клиенты не могли неконтролируемо изменять состояние вашего объекта, как своего собственного.
Переменные-члены всегда инициализируются в том порядке, в котором они объявлены при определении класса; порядок их упоминания в списке инициализации конструктора игнорируется.
Внутри конструкторов и деструкторов виртуальные функции теряют виртуальность.
Убедитесь, что при любых ошибках ваша программа всегда остается в корректном состоянии (в этом и заключается базовая гарантия). Остерегайтесь ошибок, нарушающих инвариант (включая утечки, но не ограничиваясь ими).
Для уведомления об ошибках лучше использовать механизм исключений, а не коды ошибок. Применять коды состояния следует только тогда, когда нельзя использовать исключения.
Генерируйте исключения по значению (не через указатель) и перехватывайте их как ссылки (обычно константные). Эта комбинация наилучшим образом соответствует семантике исключений.
Вызов алгоритма вместо самостоятельно разработанного цикла может оказаться более выразительным, легче сопровождаемым, менее подверженным ошибкам и не менее эффективным.
Избегайте явного выбора типа объекта для настройки поведения. Используйте шаблоны и виртуальные функции для того, чтобы поведение объекта определялось его типом, а не вызывающим кодом.
Старое преобразование типов в стиле С имеет различную (и часто опасную) семантику в зависимости от контекста, спрятанную за единым синтаксисом. Замена преобразования типов в стиле С преобразованиями С++ поможет защититься от неожиданных ошибок.
- H. Sutter, A. Alexandrescu “C++ Coding Standards. 101 Rules, Guidelines, and Best Pracitces”
- CppCoreGuidelines/CppCoreGuidelines.md at master • isocpp/CppCoreGuidelines (github.com)
- Google C++ Style Guide