…
Часть 10. Форматирование
Часть 11. Исключения из правил
Изменения 2019-2024
Эта статья является переводом части руководства Google по стилю в C++ на русский язык.
Исходная статья (fork на github), обновляемый перевод.
Исключения из правил
Соглашения по кодированию, описанные выше являются обязательными. Однако, как и в любых правилах, иногда в них есть исключения, которые сейчас и обсудим.
Существующий код, не соответствующий стилю
Допустимо отклоняться от правил, если производится работа с кодом, не соответствующим этому руководству.
Если модифицируется код, написанный другим стилем, допустимо отклоняться от требований этого руководства и использовать «местный» стиль, чтобы получить согласованный код. Если сомневаетесь — спросите автора кода (или того, кто это поддерживает). Помните, что согласованность включает также и текущий стиль кода.
Программирование под Windows
Программисты под Windows могут использовать особенный набор соглашений о кодировании, основанный на стиле заголовочных файлов в Windows и другом коде от Microsoft. Так как хочется сделать, чтобы код был понятным для всех, то рекомендуется использовать единое руководство по стилю в C++, одинаковое для всех платформ.
Повторим несколько рекомендаций, которые отличают данное руководство от стиля Windows:
- Не используйте венгерскую нотацию (например, именование целочисленной переменной как iNum). Вместо этого используйте соглашения об именовании от Google, включая расширение .cc для файлов с исходным кодом.
- Windows определяет собственные синонимы для базовых типов, такие как DWORD, HANDLE и др. Понятно, что при вызове Windows API рекомендуется использовать именно их. И всё равно, старайтесь определять типы, максимально похожие на C++. Например, используйте const TCHAR * вместо LPCTSTR.
- При компиляции кода с помощью Microsoft Visual C++ установите уровень предупреждений 3 или выше. Также установите настройку, чтобы трактовать все предупреждения как ошибки.
- Не используйте #pragma once. Вместо этого используйте стандартную защиту от повторного включения, описанную в руководстве от Google. Компоненты пути в имени для макроопределения защиты должны быть относительными к корню проекта.
- Вообще, не используйте нестандартные расширения, такие как #pragma и __declspec (исключение для случаев крайней необходимости). Использование __declspec(dllimport) и __declspec(dllexport) допустимо, однако следует оформить их как макросы DLLIMPORT и DLLEXPORT: в этом случае их можно легко заблокировать, если код будет распространяться.
С другой стороны, есть правила, которые можно нарушать при программировании под Windows:
- Обычно рекомендуется не использовать множественное наследование реализации; однако это требуется при использовании COM и некоторых классов ATL/WTL. В этом случае (при реализации COM или ATL/WTL) нарушение правила допустимо.
- Хотя использование исключений в собственном коде не рекомендуется, они интенсивно используются в ATL и некоторых STL (в том числе и в варианте библиотеки от Visual C++). Когда используете ATL, следует определить _ATL_NO_EXCEPTIONS, чтобы запретить исключения. Желательно разобраться, можно ли запретить исключения и в STL, однако, если это не реализуемо, то допустимо разрешить исключения в компиляторе. (Учтите, что это разрешено только для компиляции STL. Пользовательский код всё равно не должен содержать обработчики исключений).
- Типичный способ работы с прекомпилированными заголовочными файлами — включить такой файл первым в каждый файл исходников, обычно с именем StdAfx.h или precompile.h. Чтобы не создавать проблем при распространении кода, лучше избегать явного включения такого файла (за исключением precompile.cc). Используйте опцию компилятора /FI для автоматического включения такого файла.
- Заголовочный файлы ресурсов (обычно resource.h), содержащий только макросы, может не следовать рекомендациям этого руководства.
Заключение
Руководствуйтесь здравым смыслом и придерживайтесь ПОСТОЯНСТВА в стиле.
Если редактируете чужой код, то потратьте несколько минут и ознакомьтесь со стилем этого кода. Если в нём используются пробелы вокруг if — следует делать также. Если комментарий отчёркнут линией из звёздочек, то в свой комментарии также следует добавить такую линию.
Основное предназначение руководства по стилю — это единый базис, это общий словарь, позволяющий не отвлекаться на вопросы "… как это написать ..." и сосредоточиться на том, что написать. Здесь были описаны общие правила стиля, однако не стоит забывать и о текущем используемом стиле. Если в существующем коде делаются исправления, которые сильно отличаются от исходного кода, это усложняет чтение кода, сбивает с ритма. Постарайтесь этого избежать.
Примечания:
Изображение взято из открытого источника.