отсутствия какой-либо систематичности.
Подведем итоги.
• Хороший стандарт программирования предназначен для конкретной предметной области и конкретной группы программистов.
• Хороший стандарт программирования должен быть инструктивным, а не запретительным.
• Рекомендация некоторых основных библиотечных возможностей часто является самым эффективным способом применения инструктивных правил.
• Стандарт программирования — это совокупность правил, описывающих желательный образец для кода, в частности:
• регламентирующие способ именования идентификаторов и выравнивания строк, например “Используйте схему Страуструпа”;
• указывающие конкретное подмножество языка, например “Не используйте операторы new или throw”;
• задающие правила комментирования, например “Каждая функция должна содержать описание того, что она делает”;
• требующие использовать конкретные библиотеки, например “используйте библиотеку <iostream>, а не <stdio.h>”, или “используйте классы vector и string, а не встроенные массивы и строки в стиле языка С”.
• Большинство стандартов программирования имеет общие цели.
• Надежность.
• Переносимость.
• Удобство сопровождения.
• Удобство тестирования.
• Возможность повторного использования.
• Возможность расширения.
• Читабельность.
• Хороший стандарт программирования лучше, чем отсутствие стандарта.
Мы не начинаем ни один большой промышленный проект (т.е. проект, в котором задействовано много людей и который продолжается несколько лет), не установив стандарт программирования.
• Плохой стандарт программирования может оказаться хуже, чем полное отсутствие стандарта. Например, стандарты программирования на языке С++, суживающие его до языка С, таят в себе угрозу. К сожалению, плохие стандарты программирования встречаются чаще, чем хотелось бы.
• Программисты не любят стандарты программирования, даже хорошие. Большинство программистов хотят писать свои программы только так, как им нравится.
25.6.2. Примеры правил
В этом разделе мы хотели бы дать читателям представление о стандартах программирования, перечислив некоторые правила. Естественно, мы выбрали те правила, которые считаем полезными для вас. Однако мы не видели ни одного реального стандарта программирования, который занимал бы меньше 35 страниц. Большинство из них намного длиннее. Итак, не будем пытаться привести здесь полный набор правил. Кроме того, каждый хороший стандарт программирования предназначен для конкретной предметной области и конкретной группы программистов. По этой причине мы ни в коем случае не претендуем на универсальность.
Правила пронумерованы и содержат (краткое) обоснование. Мы провели различия между рекомендациями, которые программист может иногда игнорировать, и твердыми правилами, которым он обязан следовать. Обычно твердые правила обычно нарушаются только с письменного согласия руководителя. Каждое нарушение рекомендации или твердого правила требует отдельного комментария в программе. Любые исключения из правила должны быть перечислены в его описании. Твердое правило выделяется прописной буквой R в его номере. Номер рекомендации содержит строчную букву r.
Правила разделяются на несколько категорий.
• Общие.
• Правила препроцессора.
• Правила использования имен и размещения текста.
• Правила для классов.
• Правила для функций и выражений.
• Правила для систем с жесткими условиями реального времени.
• Правила для систем, предъявляющих особые требования к вопросам безопасности.
Правила для систем с жесткими условиями реального времени и систем, предъявляющих особые требования к вопросам безопасности, применяются только в проектах, которые явно такими объявлены.
По сравнению с хорошими реальными стандартами программирования наша терминология является недостаточно точной (например, что значит, “система, предъявляющая особые требования к вопросам безопасности”), а правила слишком лаконичны. Сходство между этими правилами и правилами JSF++ (см. раздел 25.6.3) не является случайным; я лично помогал формулировать правила JSF++. Однако примеры кодов в этой книге не следуют этим правилам — в конце концов, книга не является программой для систем, предъявляющих особые требования к вопросам безопасности.
Общие правила
R100. Любая функция или класс не должны содержать больше 200 логических строк кода (без учета комментариев).
Причина: длина функции или класса свидетельствует об их сложности, поэтому их трудно понять и протестировать.
r101. Любая функция или класс должны помещаться на экране и решать одну задачу.
Причина. Программист, видящий только часть функции или класса, может не увидеть проблему. Функция, решающая сразу несколько задач, скорее всего, длиннее и сложнее, чем функция, решающая только одну задачу.
R102. Любая программа должна соответствовать стандарту языка С++ ISO/IEC 14882:2003(E).
Причина. Расширения языка или отклонения от стандарта ISO/IEC 14882 менее устойчивы, хуже определены и уменьшают переносимость программ.
Правила препроцессора
R200. Нельзя использовать никаких макросов, за исключением директив управления исходными текстами #ifdef и #ifndef.
Причина. Макрос не учитывает область видимости и не подчиняется правилам работы с типами. Использование макросов трудно определить визуально, просматривая исходный текст.
R201. Директива #include должна использоваться только для включения заголовочных файлов (*.h).
Причина. Директива #include используется для доступа к объявлениям интерфейса, а не к деталям реализации.
R202. Директивы #include должны предшествовать всем объявлениям, не относящимся к препроцессору.
Причина. Директива #include, находящаяся в середине файла, скорее всего, будет не замечена читателем и вызовет недоразумения, связанные с тем, что область видимости разных имен в разных местах разрешается по-разному.
R203. Заголовочные файлы (*.h) не должны содержать определение не константных переменных или не подставляемых нешаблонных функций.
Причина. Заголовочные файлы должны содержать объявления интерфейсов, а не детали реализации. Однако константы часто рассматриваются как часть интерфейса; некоторые очень простые функции для повышения производительности должны быть подставляемыми (а значит, объявлены в заголовочных файлах), а текущие шаблонные реализации требуют, чтобы в заголовочных файлах содержались полные определения шаблонов.
Правила использования имен и размещения текста
R300. В пределах одного и того же исходного файла следует использовать согласованное выравнивание.
Причина. Читабельность и стиль.
R301. Каждая новая инструкция должна начинаться с новой строки.
Причина. Читабельность.
Пример:
int a = 7; x = a+7; f(x,9); // нарушение
int a = 7; // OK
x = a+7; // OK
f(x,9); // OK
Пример:
if (p<q) cout << *p; // нарушение
Пример:
if (p<q)
cout << *p; // OK
R302. Идентификаторы должны быть информативными.
Идентификаторы могут состоять из общепринятых аббревиатур и акронимов.
В некоторых ситуациях имена x, y, i, j и т.д. являются информативными.
Следует использовать стиль number_of_elements, а не numberOfElements.
Венгерский стиль использовать не следует.
Только имена типов, шаблонов и пространств имен могут начинаться с прописной буквы.
Избегайте слишком длинных имен.
Пример: Device_driver и Buffer_pool.
Причина. Читабельность.
Примечание. Идентификаторы, начинающиеся с символа подчеркивания, зарезервированы стандартом языка С++ и, следовательно,
