В какой степени нужно практиковать защитное программирование?

Question

В какой степени следует практиковать защитное программирование?

У меня есть этот код, который немного защищает, поэтому, если кто-то поменяет местами левое и правое выражение оператора OR, код все равно будет работать:*

&& ( companyId == Guid.Empty 
     || (companyId != Guid.Empty && x.StoreCompany.CompanyId == companyId) )

Вы бы выгнали меня из вашей организации, если бы я переформулировал это и сократил его до:

&& (companyId == Guid.Empty || x.StoreCompany.CompanyId == companyId)

Answer 1

Чем короче / менее запутанные логические утверждения, тем лучше. Я бы рекомендовал вам сделать такой рефакторинг.

Answer 2

Я не вижу, что, по вашему мнению, является проблемой в предлагаемом вами рефакторе.

В оригинале companyId! = Guid.Empty всегда истинно и, следовательно, бессмысленно.Почему бы не удалить его?

Answer 3

Конечно, я бы не стал загружать тебя. Скорее, я бы ожидал, что разработчики поймут последствия перемещения вещей, как вы описали. Как поменяется местами левое и правое выражения этого оператора OR?

Answer 4

Это не совсем защитное программирование. DP, воплощенный, в частности, в классических 90-х годах, том Макконнелла Code Complete , на самом деле предназначен для постепенного накопления контрфорсов в коде, которые определяются использованием. Итак, вы начинаете с некоторых базовых утверждений, а затем, когда видите, что что-то проходит через экран, вы добавляете больше.

Лично я склоняюсь к стороне Бертрана Мейера в этом спектре: контракты. Вопрос о том, сможете ли вы действительно достичь уровней «доказательства», к которым он стремится, широко обсуждается, но его стремление к защитному программированию блестяще. Чистая сеть - это любая система, которая не знает, как она может выйти из строя, пока пользователь не покажет, что это работа безумия. Компонент должен делать только одну вещь и точно предписывать, что ему нужно для этого (в предварительных условиях) и гарантировать результат (публикацию), учитывая, что больше ничего не происходит в процессе (инварианты).

Answer 5

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

ОДНАКО !!!

С точки зрения алгебраического подхода, ваш фактор не верен, я думаю.

P + (! PQ) <> P + Q

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

Answer 6

Вероятно, я бы сказал недобрые слова, если бы вы использовали первую версию в производстве.То, что вы опубликовали, - это не защитное кодирование, это избыточное кодирование.