Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

Используйте для реализации функциональности наиболее обобщенные и абстрактные средства.

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

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

• Используйте для сравнения итераторов != вместо < . Оператор !=более общий и применим к большему классу объектов; оператор <требует упорядочения и может быть реализован только итераторами произвольного доступа. При использовании оператора !=ваш код проще переносится для работы с другими типами итераторов, такими как одно- и двунаправленные итераторы.

• Лучше использовать итераторы, а не индексы. Многие контейнеры не поддерживают индексный доступ; например, контейнер listне в состоянии эффективно реализовать его. Однако все контейнеры поддерживают итераторы. Таким образом, итераторы обеспечивают большую обобщенность кода, и при необходимости они могут использоваться совместно с индексным доступом.

• Используйте empty() вместо size() == 0 . "Пуст/не пуст" — более примитивная концепция, чем "точный размер". Например, вы можете не знать размер потока, но всегда можете сказать о том, пуст он или нет; то же самое справедливо и для входных итераторов. Некоторые контейнеры, такие как list, реализуют emptyболее эффективно, чем size.

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

• Будьте корректны при использовании const (см. рекомендацию 15). Передача параметров const&накладывает меньше ограничений на вызывающий код, поскольку const&охватывает как константные, так и неконстантные объекты.

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

[Koenig97] §12.7, §17-18 • [Meyers01] §4 • [Stroustrup00] §13, §17.1.1 • [Sutter04] §1, §5, §34

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

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

В этом разделе мы считаем наиболее значимой рекомендацию 69 — "Определите разумную стратегию обработки ошибок и строго ей следуйте".

Используйте assertили его эквивалент для документирования внутренних допущений в модуле (т.е. там, где вызываемый и вызывающий код поддерживаются одним и тем же программистом или командой), которые должны всегда выполняться (в противном случае они являются следствием программной ошибки; например, нарушение постусловий функции, обнаруженное вызывающим кодом). (См. также рекомендацию 70.) Убедитесь, что использование assertне приводит к побочным действиям.

Очень трудно найти ошибку в своем коде, когда вы ищете ее; но во сто крат труднее найти ее, если вы считаете, что ее там нет.

Трудно переоценить всю мощь assert. Этот макрос и его альтернативы, такие как шаблоны проверки времени компиляции (или, что несколько хуже, времени выполнения), представляют собой неоценимый инструментарий для обнаружения и отладки программных ошибок при работе над проектами. Среди прочих инструментов у них, пожалуй, наилучшее отношение сложность/эффективность.

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

assert(++i < limit); // Плохо: i увеличивается только в

// отладочном режиме

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

Избегайте применения assert(false), лучше использовать assert(!"информационное сообщение"). Большинство компиляторов вставят строку в вывод сообщения об ошибке. Подумайте также о добавлении &&"информационное сообщение"к более сложным проверкам вместо комментария.

Рассмотрим определение вашего собственного assert. Стандартный макрос assertпросто бесцеремонно завершает вашу программу с выводом сообщения в стандартный поток вывода. Ваша среда, вероятно, обладает расширенными возможностями отладки; пусть, например, она в состоянии автоматически запустить интерактивный отладчик. В этом случае вы можете определить собственный макрос MYASSERTи использовать его. Может также оказаться полезным оставить большинство проверок даже в окончательной версии программы (лучше не отключать проверки по соображениям эффективности, пока необходимость этого