Правила пронумерованы и содержат (краткое) обоснование. Мы провели различия между рекомендациями, которые программист может иногда игнорировать, и твердыми правилами, которым он обязан следовать. Обычно твердые правила обычно нарушаются только с письменного согласия руководителя. Каждое нарушение рекомендации или твердого правила требует отдельного комментария в программе. Любые исключения из правила должны быть перечислены в его описании. Твердое правило выделяется прописной буквой R в его номере. Номер рекомендации содержит строчную букву r.

Правила разделяются на несколько категорий.

• Общие.

• Правила препроцессора.

• Правила использования имен и размещения текста.

• Правила для классов.

• Правила для функций и выражений.

• Правила для систем с жесткими условиями реального времени.

• Правила для систем, предъявляющих особые требования к вопросам безопасности.

Правила для систем с жесткими условиями реального времени и систем, предъявляющих особые требования к вопросам безопасности, применяются только в проектах, которые явно такими объявлены.

По сравнению с хорошими реальными стандартами программирования наша терминология является недостаточно точной (например, что значит, “система, предъявляющая особые требования к вопросам безопасности”), а правила слишком лаконичны. Сходство между этими правилами и правилами JSF++ (см. раздел 25.6.3) не является случайным; я лично помогал формулировать правила JSF++. Однако примеры кодов в этой книге не следуют этим правилам — в конце концов, книга не является программой для систем, предъявляющих особые требования к вопросам безопасности.

Общие правила

R100. Любая функция или класс не должны содержать больше 200 логических строк кода (без учета комментариев).

Причина: длина функции или класса свидетельствует об их сложности, поэтому их трудно понять и протестировать.

r101. Любая функция или класс должны помещаться на экране и решать одну задачу.

Причина. Программист, видящий только часть функции или класса, может не увидеть проблему. Функция, решающая сразу несколько задач, скорее всего, длиннее и сложнее, чем функция, решающая только одну задачу.

R102. Любая программа должна соответствовать стандарту языка С++ ISO/IEC 14882:2003(E).

Причина. Расширения языка или отклонения от стандарта ISO/IEC 14882 менее устойчивы, хуже определены и уменьшают переносимость программ.

Правила препроцессора

R200. Нельзя использовать никаких макросов, за исключением директив управления исходными текстами

и .

Причина. Макрос не учитывает область видимости и не подчиняется правилам работы с типами. Использование макросов трудно определить визуально, просматривая исходный текст.

R201. Директива

должна использоваться только для включения заголовочных файлов ().

Причина. Директива

используется для доступа к объявлениям интерфейса, а не к деталям реализации.

R202. Директивы

должны предшествовать всем объявлениям, не относящимся к препроцессору.

Причина. Директива

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

R203. Заголовочные файлы (

) не должны содержать определение не константных переменных или не подставляемых нешаблонных функций.

Причина. Заголовочные файлы должны содержать объявления интерфейсов, а не детали реализации. Однако константы часто рассматриваются как часть интерфейса; некоторые очень простые функции для повышения производительности должны быть подставляемыми (а значит, объявлены в заголовочных файлах), а текущие шаблонные реализации требуют, чтобы в заголовочных файлах содержались полные определения шаблонов.

Правила использования имен и размещения текста

R300. В пределах одного и того же исходного файла следует использовать согласованное выравнивание.

Причина. Читабельность и стиль.

R301. Каждая новая инструкция должна начинаться с новой строки.

Причина. Читабельность.

Пример: