Библиотека программиста

Все, что необходимо начинающему и опытному программисту

16. Избегайте макросов

Резюме

Макрос — самый неприятный инструмент С и C++, оборотень, скрывающийся под личиной функции, кот, гуляющий сам по себе и не обращающий никакого внимания на границы ваших областей видимости. Берегитесь его!

Обсуждение

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

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

Мне не нравится большинство видов препроцессоров и макросов. Одна из целей C++ — сделать препроцессор C излишним (§4.4, §18), поскольку я считаю его большой ошибкой.

Макросы почти никогда не являются необходимыми в C++. Используйте const (§5.4) или enum (§4.8) для определения явных констант [см. рекомендацию 15], inline (§7.1.1) для того, чтобы избежать накладных расходов на вызов функции [но см. рекомендацию 8], template (глава 13) для определения семейств функций и типов [см. рекомендации с 64 по 67], и namespace (§8.2) для того, чтобы избежать конфликтов имен

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

Основная проблема с макросами C++ заключается в том, что они выглядят гораздо привлекательнее, чем являются таковыми на самом деле. Макросы игнорируют области видимости, игнорируют прочие возможности и правила языка, и заменяют все символы, которые переопределяют при помощи директивы #define, до самого конца файла. Применение макросов внешне походит на имя или вызов функции, но не имеет с ними ничего общего. Макросы "негигиеничны", в том смысле, что они могут быть раскрыты неожиданно, причем превратиться в зависимости от контекста их использования в самые разные конструкции. Подстановка текста, выполняемая макросами, делает написание хотя бы в небольшой степени "приличного" макроса смесью искусства и черной магии.

Программисты, которые полагают, что тяжелее всего расшифровать ошибки, связанные с шаблонами, вероятно, просто никогда не имели дела с плохо написанными или неверно использованными макросами. Шаблоны являются частью системы типов C++, и тем самым позволяют компилятору куда лучше справляться с ними, чем с макросами, которые имеют мало общего с языком программирования. Хуже того, в отличие от шаблонов неверные макросы могут быть раскрыты в нечто, что в силу чистой случайности скомпилируется, не имея при этом никакого смысла. И наконец, ошибка в макросе обнаруживается только после того, как макрос раскрывается, а не при его определении.

Даже в тех редких случаях, где применение макросов оправданно (см. подраздел, посвященный исключениям), нельзя даже подумать о том, чтобы написать макрос, который является распространенным словом или аббревиатурой. Для всех макросов как можно скорее применяйте директиву #undef, всегда давая им необычные уродливые имена в верхнем регистре, избегая при этом размещения их в заголовочных файлах.

Примеры

Пример. Передача инстанцирования шаблона макросу. Макросы понимают в достаточной мере только круглые и квадратные скобки. В C++, однако, определена новая конструкция с угловыми скобками, используемая в шаблонах. Макросы не могут корректно обработать эту ситуацию, так что вызов

MACRO( Foo<int, double> )

макрос воспринимает так, будто ему переданы два аргумента, а именно Foo<int и double>, в то время как в действительности эта конструкция представляет собой единый объект C++.

Исключения

Макросы остаются единственно возможным решением для некоторых важных задач, таких как защита директивы #include (см. рекомендацию 24), использование директив #ifdef и #if defined для условной компиляции и реализация assert (см. рекомендацию 68).

При условной компиляции (например, системно-зависимых частей) избегайте разброса по всему тексту директив #ifdef. Вместо этого лучше организовать код таким образом, чтобы использование макросов обеспечивало возможность альтернативных реализаций одного общего интерфейса, который затем будет использоваться в программе.

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

17. Избегайте магических чисел

Резюме

Избегайте использования в коде литеральных констант наподобие 42 или 3.1415926. Такие константы не самоочевидны и усложняют сопровождение кода, поскольку вносят в него трудноопределимый вид дублирования. Используйте вместо них символьные имена и выражения наподобие width*aspectRatiо.

Обсуждение

Имена добавляют информацию и вводят единую точку сопровождения; в отличие от них дублированные по всей программе обычные числа анонимны и трудно сопровождаемы. Константы должны быть перечислениями или const-значениями, с соответствующими областями видимости и именами.

Одно число 42 может не быть тем же числом 42, что и другое. Что еще хуже, программист может выполнять какие-то вычисления "в уме" (например: "Вот это 84 — просто удвоенное 42, которое было пятью строками ранее"), что совершенно запутывает код и делает последующую замену 42 другой константой источником огромного количества ошибок.

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

Примеры

Пример 1. Важные константы из предметной области на уровне пространств имен.

const size_t PAGE_5IZE          = 8192,
             WORDS_PER_PAGE     = PAGE_SIZE / sizeof(int),
             INFO_BITS_PER_PAGE = 32 * CHAR_BIT;

Пример 2. Константы, специфичные для данного класса. Вы можете определить статические интегральные константы в определении класса; константы других типов требуют отдельного определения или применения коротких функций.

// Файл widget.h
class Widget {
    // Значение указано в объявлении
    static const int defaultWidth = 400;
    // Значение указано в определении
    static const double defaultPercent;
    static const char* Name() { return "Widget"; }
};

// Файл widget.cpp
    // Значение указано в определении
    const double Widget::defaultPercent = 66.67;
    // Требуется объявление
    const int Widget::defaultWidth;

18. Объявляйте переменные как можно локальнее

Резюме

Избегайте "раздувания" областей видимости. Переменных должно быть как можно меньше, а время их жизни — как можно короче. Эта рекомендация по сути является частным случаем рекомендации 10.

Обсуждение

Переменные, время жизни которых превышает необходимое, имеют ряд недостатков.

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

• Они засоряют контекст своими именами. Непосредственным следствием является то, что переменные на уровне пространства имен, наиболее видимые среди всех остальных, одновременно являются и наихудшими (см. рекомендацию 10).

• Они не всегда могут быть корректно инициализированы. Никогда не объявляйте переменную до того, как вы сможете корректно ее инициализировать. Неинициализированные переменные — источник "расползающихся" ошибок во всех программах С и C++, и требуют особого внимания в связи с тем, что не всегда могут быть обнаружены компилятором (см. рекомендацию 19).

В частности, старые версии языка С требовали, чтобы переменные были определены только в начале области видимости; такой стиль в C++ вышел из употребления. Серьезная проблема такого ограничения состоит в том, что зачастую в начале области видимости не имеется достаточной информации для инициализации переменных. В результате у вас остается два выхода — либо инициализировать переменные некоторым значением по умолчанию (например, нулем), что обычно расточительно и может привести к ошибкам (если переменная будет использована до того, как приобретет некоторое осмысленное значение), либо оставить их неинициализированными, что опасно. Неинициализированная переменная пользовательского типа будет самоинициализироваться некоторым пустым значением.

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

Исключения

Иногда с точки зрения производительности может оказаться выгодным вынесение переменной за пределы цикла (см. рекомендацию 9).

Поскольку константы не являются частью состояния программы, данная рекомендация на них не распространяется (см. рекомендацию 17).

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru