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

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

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

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

25.6.1. Каким должен быть стандарт программирования?

Хороший стандарт программирования должен способствовать написанию хороших программ; т.е. должен давать программистам ответы на множество мелких вопросов, решение которых в каждом конкретном случае привело бы к большой потере времени. Старая поговорка программистов гласит: “Форма освобождает”. В идеале стандарт кодирования должен быть инструктивным, указывая, что следует делать. Это кажется очевидным, но многие стандарты программирования представляют собой простые списки запрещений, не содержащие объяснений, что с ними делать. Простое запрещение редко бывает полезным и часто раздражает.

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

10

“верблюжий стиль”. — Примеч. ред.

11

“стиль с подчеркиванием”. — Примеч. ред.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Общие.

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

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

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

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

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

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

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

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