Руководство по стилизации кода на C++

C++ — компилируемый объектно-ориентированный язык программирования общего назначения. Его используют огромное количество организаций по всему миру. При разработке программ на C++ важно придерживаться определённого стиля, чтобы в дальнейшем можно было без проблем отлаживать, читать и поддерживать код. Цель этого руководства — рассказать о правилах, которых следует придерживаться при разработке программного обеспечения на C++. Отметим, что это не учебное пособие по C++, и мы предполагаем, что читатель уже знаком с этим языком.

В настоящее время код должен быть написан с использованием возможностей C++20 и не должен применять функции из C++23. Избегайте использования нестандартных расширений для C++, если это не требуется. Компиляторы могут поддерживать различные расширения, которые не входят в стандарт C++. Эти расширения включают такие элементы, как GCC attribute, встроенные функции типа __builtin_prefetch или SIMD, директивы #pragma, встроенные ассемблерные вставки, макросы вроде COUNTER или PRETTY_FUNCTION, составные выражения (например, foo = ({ int x; Bar(&x); x })), массивы переменной длины, функции вроде alloca(), и оператор a?. Хотя нестандартные расширения могут предоставлять полезные функции, отсутствующие в стандартном C++, и могут быть необходимы для оптимизации производительности компилятора, они не всегда поддерживаются всеми компиляторами. Использование таких расширений снижает переносимость кода, поскольку они могут работать по-разному в различных компиляторах. Даже если расширение поддерживается всеми целевыми компиляторами, его реализация может отличаться, что приводит к неоднозначностям в поведении. Применение нестандартных расширений усложняет код, требуя от разработчика знания этих расширений для его понимания и переноса на другие архитектуры. Поэтому не используйте нестандартные расширения, за исключением случаев, когда вы используете их в обертках, которые обеспечивают переносимость. В таком случае такие обертки должны быть включены в специально отведенный заголовок для всего проекта.

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

Строки кода не должны превышать 80 символов, так как это стандарт, которому следует большинство кодов. Сторонники правила утверждают, что оно помогает при работе с несколькими окнами, где нет места для расширения. Противники считают, что ограничение в 80 символов устарело и делает код менее читаемым на современных экранах. Исключения допускаются для длинных комментариев, строковых литералов, инструкций include, защиты заголовков и using-объявлений, которые нельзя разбить без потери удобства. В таких случаях Clang-Format может быть отключён.

Символы, которые не входят в набор ASCII, должны использоваться редко и только в формате UTF-8. Желательно не встраивать текст пользователя напрямую в исходный код, даже если это текст на английском, поэтому символы, отличные от ASCII, следует использовать минимально. Однако в некоторых случаях это может быть оправдано. Например, если ваш код работает с данными из файлов иностранных источников, имеет смысл закодировать строки, не входящие в ASCII, если они используются в этих данных как разделители. Аналогично, тестовые коды, которые не нуждаются в локализации, могут включать такие строки. В таких ситуациях лучше использовать UTF-8, поскольку эта кодировка поддерживается большинством инструментов, которые работают не только с ASCII.

Допустимо и даже рекомендуется использовать шестнадцатеричную кодировку там, где это улучшает читаемость. Например, "\xEF\xBB\xBF" или "\uFEFF" обозначают символ нулевой ширины без разрыва в Юникоде, который был бы невидим, если бы был напрямую включен в исходный код как UTF-8. По возможности избегайте использования префикса u8, так как его поведение значительно изменилось в C++20 по сравнению с C++17 и будет снова изменено в C++23. Не стоит использовать типы char16_t и char32_t, так как они предназначены для текстов, не относящихся к UTF-8. По той же причине избегайте wchar_t, если только вы не пишете код для работы с Windows API, где этот тип используется широко.

Полностью вы сможете прочитать наше руководство на сайте Case Technologies.

Ссылка: