Насколько «защитным» должен быть мой код? - PullRequest
12 голосов
/ 15 мая 2009

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

Как вы знаете, где провести линию?

Ответы [ 15 ]

14 голосов
/ 15 мая 2009

Если пользователь вводит прямо или косвенно, вы должны всегда проверять работоспособность. Кроме того, несколько assert здесь и там не повредит, но вы все равно ничего не можете поделать с сумасшедшими программистами, редактирующими и нарушающими ваш код! -)

11 голосов
/ 15 мая 2009

Я склонен менять степень защиты, которую я помещаю в свой код, в зависимости от языка. Сегодня я в основном работаю в C ++, поэтому мои мысли движутся в этом направлении.

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

9 голосов
/ 15 мая 2009

Я не фанат термина "защитное программирование". Для меня это предлагает код, подобный этому:

void MakePayment( Account * a, const Payment * p ) {
    if ( a == 0 || p == 0 ) {
       return;
    }
    // payment logic here
}

Это неправильно, неправильно, неправильно, но я, наверное, видел это сотни раз. Эта функция никогда не должна была вызываться с нулевыми указателями, и совершенно неправильно их принимать.

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

Редактировать: Я не согласен с некоторыми другими ответами и комментариями здесь - я не думаю, что все функции должны проверять свои параметры (для многих функций это просто невозможно). Вместо этого я считаю, что все функции должны документировать приемлемые значения и указывать, что другие значения приведут к неопределенному поведению. Именно такой подход используют самые успешные и широко используемые библиотеки из когда-либо написанных - стандартные библиотеки C и C ++.

А теперь пусть начнутся отрицательные голоса ...

4 голосов
/ 15 мая 2009

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

В конечном счете, я думаю, что это просто то, что человек должен следовать своей интуиции. Нет правильного или неправильного способа сделать это.

2 голосов
/ 15 мая 2009

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

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

1 голос
/ 15 мая 2009

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

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

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

1 голос
/ 15 мая 2009

Моя личная идеология: защита программы должна быть пропорциональна максимальной наивности / незнанию потенциальной базы пользователей.

1 голос
/ 15 мая 2009

Я всегда отлаживаю. Утверждаю свои предположения.

0 голосов
/ 05 августа 2009

Хороший вопрос, я переключился между выполнением проверок работоспособности и не выполнением их. Это 50/50

Ситуация, я бы, вероятно, выбрал золотую середину, где я бы только "Пуленепробиваемый" любые подпрограммы, которые:

(a) Вызывается из более чем одного места в проекте

(b) имеет логику, которую СКОЛЬКО можно изменить

(c) Нельзя использовать значения по умолчанию

(d) изящная процедура не может быть «неудачной»

Darknight

0 голосов
/ 15 мая 2009

У меня недавно был сценарий, в котором пользовательские входные данные распространялись через интерфейс удаленного фасада, затем через локальный интерфейс фасада, затем через какой-то другой класс, чтобы, наконец, добраться до метода, где они фактически использовались. Я задавал себе вопрос: Когда должно быть проверено значение? Я добавил код проверки только в последний класс, где значение фактически использовалось. Добавление других фрагментов кода проверки в классы, лежащие на пути распространения, было бы слишком защитным программированием для меня. Единственным исключением может быть удаленный фасад, но я тоже его пропустил.

...