Стиль программирования на C++

Основное правило:

• Пишите код в том же стиле, что и окружающий его код.

Данный документ описывает руководства, которые новички в проекте могут не сразу заметить. Эти правила не являются универсальными (кроме первого правила), и ситуации могут требовать лучшего суждения.

1. Используйте конструкцию if (...) {, while (...) {, и switch (...) {, а не if (...){}, while (...){}, и switch (...){}. Всегда используйте фигурные скобки.

2. Заголовочные файлы следует включать в следующем порядке:

3. Ваш родительский файл .hpp (если вы являетесь файлом .cc),

4. Заголовочные файлы системного уровня C (<math.h>, <unistd.h> и т.д.),

5. Заголовочные файлы стандартной библиотеки C++ (<vector>, <algorithm> и т.д.),

6. Заголовочные файлы библиотеки Boost, с условием, что файл "errors.hpp" включен перед ними, если такие файлы есть,

7. Локальные заголовочные файлы с полными путями ("rdb_protocol/protocol.hpp" и т.д.).

Причина: всегда полезно иметь один файл .cc, который включает каждый файл .hpp первым, чтобы знать, что он включает все свои зависимости. Гайдлайн Google указывает на порядок C/C++/Локальных файлов, и мы принимаем это как данность. Файл "errors.hpp" определяет BOOST_ENABLE_ASSERT_HANDLER, чтобы сделать ошибки проверки условий Boost совместимыми с механизмом проверки условий RethinkDB, поэтому ему требуется быть включенными до заголовочных файлов Boost.3. Избегайте использования неконстантных ссылок на значения, за исключением случаев, когда они используются в качестве значений возврата.

Причина: весь код основан на этом подходе. Сейчас, кто-то, видящий вызов foo(bar), может ожидать, что bar не будет модифицироваться.

Исключение: методы std::swap и аналогичные им методы swap других библиотек, а также другие особые случаи.

4. Не создавайте поля типа ссылка (константная или неконстантная), и не преобразуйте ссылки в указатели способами, которые могут удивить вызывающего кода.

Причина: Это делает зависимости жизненного цикла объектов более очевидными (кто-то, вызывающий foo(bar), может предположить, что нет новых ограничений на жизненный цикл bar — код должен стать foo(&bar), что показывает, что происходит что-то странное).

Ошибки доступа к пустому указателю легче отслеживать, чем ошибки использования после освобождения. Также, они обычно не происходят: функция, принимающая аргумент типа указатель, не подразумевает, что она принимает значение пустого указателя, и это ещё не было проблемой.

5. Если ваш тип не должен копироваться, используйте макрос DISABLE_COPYING, чтобы сделать его недоступным для копирования. > Или объявите его конструктор копий и оператор присваивания с = delete; самостоятельно.6. Выполните (из директории src) команду ../scripts/check_style.sh, чтобы проверить, не внесли ли вы определенного типа стилистических ошибок.

Ошибки include-what-you-use существуют, чтобы заставить вас страдать — но осознание этого делает усилия по развязыванию зависимостей заголовочных файлов намного менее трудоёмкими.

Ложноположительные ошибки можно отключить с помощью // NOLINT(specific/category).

Этот скрипт поймал несколько багов (в основном связанных с расконфликтованием вызовов функций libc, не использующих рекурсивных "_r" версий).