Предварительные условия должны ВСЕГДА проверяться? [закрытый]

По моему опыту, это зависит от вашей инкапсуляции. Если внутренняя функция является частной, вы можете быть уверены, что ее предварительные условия установлены.

Думаю, все дело в Законе Деметры, говори только с друзьями и так далее.

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

Лучше всего всегда проверять их.

если функция делегирует полномочия другой функции, то первая функция должна делегировать полномочия другой функции. функции, первая функция должна проверить их, но проверять их снова во второй - это лишнее.

А что если изменить способ вызова этих функций друг у друга? Или вы вводите новые требования к проверке во второй функции, которой делегируется первая? Я бы сказал, что безопаснее всегда проверять их.

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

Отладка

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

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

QA

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

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

Документация

Если у вас мало времени на создание документации, вы можете сделать так, чтобы ваш код помогал сопровождающему его тексту. Четкие и видимые проверки предусловий, которые воспринимаются отдельно от остальной реализации, в некоторой степени "документируют" возможные входы. (Другой способ документировать код таким образом - написание модульных тестов).

Я думаю, это зависит от того, как организована команда: проверяйте входные данные, поступающие извне команда.

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

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

Как и во всем, оцените свои требования, чтобы найти лучшее решение для каждой ситуации.

Когда предусловия легче проверить ("указатель не null"), вы можете делать это часто. Предварительные условия, которые трудно проверить ("указывает на допустимую строку с нулевым окончанием") или требуют больших затрат времени, памяти или других ресурсов, можно обрабатывать по-другому. Используйте принцип Парето и собирайте низко висящие плоды.

// C, C++:
void example(char const* s) {
  // precondition: s points to a valid null-terminated string
  assert(s); // tests that s is non-null, which is required for it to point to
  // a valid null-terminated string.  the real test is nearly impossible from
  // within this function
}

Гарантирование предварительных условий является обязанностью вызывающей стороны. В связи с этим некоторые языки предлагают конструкцию "assert", которую по желанию можно пропустить (например, определение NDEBUG для C/C++, переключатель командной строки для Python), чтобы вы могли более подробно тестировать предусловия в специальных сборках без влияния на конечную производительность. Однако, как использовать assert может быть жаркой дискуссией - опять же, выясните свои требования и будьте последовательны.

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

В идеале производственная система не будет иметь штрафа в виде утверждений, и вы даже можете использовать механизм, подобный Design By Contract (TM), для статической обработки утверждений.