Обучающие курсы:

Обучение профессии "Разработчик C#" + стажировка в Mail.ru
Обучение профессии "Разработчик Python" + трудоустройство
Обучение профессии "Веб-разработчик" + стажировка в Mail.ru


Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
Стандарты для C++
Уроки по C#
Уроки по Python
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей







67. Пишите максимально обобщенный код

Резюме

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

Обсуждение

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

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

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

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

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

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

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

Исключения

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

Обработка ошибок и исключения

Обработка ошибок — сложная задача, при решении которой программисту требуется вся помощь, которая только может быть предоставлена.
— Бьярн Страуструп (Bjarne Stroustrup).

Имеется три способа написать программу без ошибок; но работает только третий способ.
— Алан Перлис (Alan Perlis)

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

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

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

68. Широко применяйте assert для документирования внутренних допущений и инвариантов

Резюме

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

Обсуждение

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

что ее там нет.

— Стив Мак-Коннелл (Steve McConnell)

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

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

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

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

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

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

Проверки зачастую связаны с условиями, которые можно было бы протестировать во время компиляции, если бы язык был достаточно выразителен для этого. Например, ваш проект может полагаться на то, что каждый объект класса Employee имеет ненулевой идентификатор id_. В идеале компилятор мог бы анализировать конструктор Employee и его члены и доказать при помощи статического анализа, что указанное условие всегда выполняется. В реальной ситуации вы можете использовать assert(id_!=0) в реализации Employee:

unsigned int Employee::GetID() {
assert(id_!=0 && "Employee  ID должен быть ненулевым");
return id_;

He используйте assert для сообщения об ошибках времени выполнения (см. рекомендации 70 и 72). Например, не следует применять assert, чтобы убедиться в корректной работе malloc, успешном создании окна или запуске потока программы. Однако можно использовать assert, чтобы убедиться, что API работает так, как документировано. Например, если вы вызываете некоторую функцию API, в документации на которую сказано, что она всегда возвращает положительное значение, но вы подозреваете наличие в ней ошибки — после вызова этой функции можно воспользоваться assert для проверки выполнения постусловия.

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

Резюмируя: имеются ошибки, о которых вы знаете, что они могут произойти (см. рекомендации с 69 по 75). Все остальные ошибки произойти не должны, и если это все же случается — то это ошибка программиста. Для таких ошибок имеется assert.

Примеры

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

string Date::DayOfWeek() const {
    // проверка инвариантов
    assert( day_ > 0 && day_ <= 31 );
    assert( month_ > 0 && month_ <= 12 );
    // ...
}

69. Определите разумную стратегию обработки ошибок и строго ей следуйте

Резюме

Еще на ранней стадии проектирования разработайте практичную, последовательную и разумную стратегию обработки ошибок и строго следуйте ей. Убедитесь, что ваша стратегия включает следующее.

  • Идентификация: какие условия являются ошибкой.

  • Строгость: насколько важна каждая ошибка.

  • Обнаружение: какой код отвечает за обнаружение ошибки.

  • Распространение: какой механизм используется для описания и распространения уведомления об ошибке в каждом модуле.

  • Обработка: какой код отвечает за выполнение действий, связанных с ошибкой.

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

Изменяйте механизмы обработки ошибок только в пределах границ модуля.

Обсуждение

В этой рекомендации мы рассматриваем ошибки времени выполнения, возникновение которых не связано с неверным кодированием (таким ошибкам посвящена рекомендация 68).

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

    Везде.

  • Определение ошибок. Для каждой сущности (например, для каждой функции, класса, модуля) документируйте внутренние и внешние инварианты.

    Для каждой функции.

  • Определение ошибок. Для каждой функции документируйте ее пред- и постусловия, инварианты, за которые она отвечает, и гарантии безопасности, которые она поддерживает (см. рекомендации 70 и 71). Заметим, что деструкторы и функции освобождения ресурсов должны всегда поддерживать гарантию бессбойности, поскольку в противном случае часто невозможно надежно и безопасно выполнить освобождение захваченных ресурсов (см. рекомендацию 51).

    Для каждой ошибки (см. определение "ошибки" в рекомендации 70).

  • Серьезность ошибки и категоризация. Для каждой ошибки определите уровень серьезности. Желательно предоставить способ тонкой настройки диагностики для определенных категорий и уровней ошибок.

  • Обнаружение ошибок. Для каждой ошибки документируйте, какой именно код отвечает за ее обнаружение, следуя советам рекомендации 70.

  • Обработка ошибок. Для каждой ошибки определите код, который отвечает за ее обработку, следуя советам рекомендации 74.

  • Уведомление об ошибках. Для каждой ошибки определите соответствующий метод уведомления. Сюда входят запись на диск в журнальный файл, распечатка или даже отправка SMS на мобильный телефон администратора.

    Для каждого модуля.

  • Передача ошибки. Для каждого модуля (обратите внимание: для каждого модуля, а не для каждой ошибки) определите механизм, который будет использоваться для передачи информации об ошибке (например, исключения C++, исключения СОМ, исключения CORBA, коды возврата).

Мы уже подчеркивали, что стратегия обработки ошибок может изменяться только на границах модулей (см. рекомендации 62 и 63). Каждый модуль должен последовательно использовать единую стратегию обработки ошибок внутри модуля (например, модули, написанные на C++, должны использовать исключения; см. рекомендацию 72), и последовательно пользоваться единой, хотя, возможно, иной стратегией обработки ошибок для своего интерфейса (например, модуль может предоставлять обычный API на языке С, чтобы обеспечить возможность его использования кодом, написанном на разных языках программирования; или использовать оболочку СОМ и, соответственно, исключения СОМ).

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

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



 
 

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