Программирование. Принципы и практика использования C++ Исправленное издание

  Правила хорошего стандарта программирования должны допускать проверку, желательно с помощью программ. Другими словами, как только вы написали программу, вы должны иметь возможность легко ответить на вопрос: “Не нарушил ли я какое-нибудь правило стандарта программирования?” Хороший стандарт программирования должен содержать обоснование своих правил. Нельзя просто заявить программистам: “Потому что вы должны делать именно так!” В ответ на это они возмущаются. И что еще хуже, программисты постоянно стараются опровергнуть те части стандарта программирования, которые они считают бессмысленными, и эти попытки отвлекают их от полезной работы. Не ожидайте, что стандарты программирования ответят на все ваши вопросы. Даже самые хорошие стандарты программирования являются результатом компромиссов и часто запрещают делать то, что лишь может вызвать проблемы, даже если в вашей практике этого никогда не случалось. Например, очень часто источником недоразумений становятся противоречивые правила именования, но люди часто отдают предпочтение определенным соглашениям об именах и категорически отвергают остальные. Например, я считаю, что имена идентификаторов вроде CamelCodingStyle[10] весьма уродливы, и очень люблю имена наподобие underscore_style[11], которые намного понятнее, и многие люди со мной согласны. С другой стороны, многие разумные люди с этим не согласны. Очевидно, ни один стандарт именования не может удовлетворить всех, но в данном случае, как и во многих других, последовательность намного лучше отсутствия какой-либо систематичности.

Подведем итоги.

• Хороший стандарт программирования предназначен для конкретной предметной области и конкретной группы программистов.

• Хороший стандарт программирования должен быть инструктивным, а не запретительным.

• Рекомендация некоторых основных библиотечных возможностей часто является самым эффективным способом применения инструктивных правил.

• Стандарт программирования — это совокупность правил, описывающих желательный образец для кода, в частности:

• регламентирующие способ именования идентификаторов и выравнивания строк, например “Используйте схему Страуструпа”;

• указывающие конкретное подмножество языка, например “Не используйте операторы new или throw”;

• задающие правила комментирования, например “Каждая функция должна содержать описание того, что она делает”;

• требующие использовать конкретные библиотеки, например “используйте библиотеку , а не ”, или “используйте классы vector и string, а не встроенные массивы и строки в стиле языка С”.

• Большинство стандартов программирования имеет общие цели.

• Надежность.

• Переносимость.

• Удобство сопровождения.

• Удобство тестирования.

• Возможность повторного использования.

• Возможность расширения.

• Читабельность.

  • Хороший стандарт программирования лучше, чем отсутствие стандарта.

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

  • Плохой стандарт программирования может оказаться хуже, чем полное отсутствие стандарта. Например, стандарты программирования на языке С++, суживающие его до языка С, таят в себе угрозу. К сожалению, плохие стандарты программирования встречаются чаще, чем хотелось бы.

• Программисты не любят стандарты программирования, даже хорошие. Большинство программистов хотят писать свои программы только так, как им нравится.

25.6.2. Примеры правил

В этом разделе мы хотели бы дать читателям представление о стандартах программирования, перечислив некоторые правила. Естественно, мы выбрали те правила, которые считаем полезными для вас. Однако мы не видели ни одного реального стандарта программирования, который занимал бы меньше 35 страниц. Большинство из них намного длиннее. Итак, не будем пытаться привести здесь полный набор правил. Кроме того, каждый хороший стандарт программирования предназначен для конкретной предметной области и конкретной группы программистов. По этой причине мы ни в коем случае не претендуем на универсальность.

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

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

• Общие.

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

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

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

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

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

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