Использование ELSE плохое программирование? [закрыто]

Я часто сталкивался с ошибками, которые были вызваны использованием ELSEконструкции. Ярким примером является что-то вроде:

If (passwordCheck() == false){
    displayMessage();
}else{
    letThemIn();
}

Для меня это крики проблема безопасности. Я знаю, что passwordCheck, вероятно, будет логическим, но я бы не стал защищать свои приложения. Что будет, если это строка, int и т. Д.?

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

Конечно, это лучший способ предотвратить появление ошибок / проблем с безопасностью в вашем приложении.

Как вы, ребята, делаете это?

elseБлок должен всегда состоять из того, что вы хотите по умолчанию быть.

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

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

If (passwordCheck)
{
   letThemIn();
}
else
{
   displayMessage();
}

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

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

Нет, в этом нет ничего плохого ELSE. ELSEне новый GOTO. Фактически, использование двух IFs вместо ELSEможет привести к нескольким проблемам.

Пример первый:

if (this(is(a(very())==complex(check())))) {
   doSomething();
}

if (!this(is(a(very())==complex(check())))) {
   doTheOtherThing();
}

Вы видите копировальную пасту? Он просто ждет того дня, когда вы поменяете одно и забудете другое.

Пример два:

foreach(x in y) {
  if (first_time) {
    first_time = false;
    doSomething();
  }

  if (!first_time) {
    doTheOtherThing();
  }
}

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

Всегда есть ДРУГОЕ. Если ты пишешь

if(foo)
  bar();

ты на самом деле пишешь

if(foo)
{
  bar();
}
else
{
   // do nothing
}

Все, что вы вставите в ELSE-путь, является вашей ответственностью.

Я лично стараюсь избегать elseкак можно больше, но это не из-за проблем с безопасностью .

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

if (checkPassword != OK) { displayMessage(); return; }

letThemIn();

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

Крис Латтнер говорит, что это лучше, чем я в стандартах кодирования LLVM .

Тогда просто замени их,

If (passwordCheck == true)
{
     letThemIn();
}
else
{
     displayMessage();
}

Как и Matthieu M., я предпочитаю ранний выход из глубоко вложенных блоков else ... Это хорошо иллюстрирует защитное программирование (если плохие условия, нет смысла продолжать). Многие люди не согласятся с нами, предпочитая уникальную точку выхода; это не точка обсуждения (я думаю).

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

Обратите внимание, что некоторые сторонники функционального программирования предлагают полностью избавиться ifв пользу сопоставления с образцом ... Слишком экстремально, на мой вкус. :-)

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

Попытайтесь удалить ELSE, если можете, но не будьте параноиком по этому поводу. Стив Макконнелл называет этот прямой код в Code Complete. Т.е. есть простой четкий путь через ваш код.

Подходы для решения вашей конкретной проблемы:

• использовать полиморфизм. На границе с вашей системой проверьте учетные данные пользователя. Если они законны, верните объект сеанса - с доступом к соответствующим частям системы или сгенерируйте исключение. Однако это может сделать вашу систему более сложной. Таким образом, вы решаете, что легче понять и поддерживать.

В целом, следующее может помочь уменьшить количество ELSE в вашем коде:

• Хорошие требования могут уменьшить потребность в таких решениях в коде. Возможно, вам вообще не понадобится реализовывать вариант использования (еще).
• более четкий дизайн. Максимальное сцепление и минимизация сцепления. Это гарантирует, что компоненты не дублируют решения, принятые в других компонентах.
• обработка исключений для управления ошибками.
• полиморфизм (см. пример выше).
• операторы switch - это прославленные ELSE, но они лучше в определенных ситуациях.

Ваше предположение о том, что код является утечкой, может быть или не быть правдой в зависимости от языка, который вы используете. В коде C это может быть проблемой (особенно потому, что в C булево значение - это просто int, отличное от нуля или нуля), но в наиболее строго типизированных языках (например, проверка типа во время выполнения), если passwordCheckпеременная была объявлена ​​как логическое значение, нет никакого способа назначить что-то еще этому. Фактически, все в ifпредикате должно разрешаться до логического значения, используете ли вы логические операторы или просто используете значение. Если вам удалось привязать другой объект к passwordCheckсреде выполнения, то возникнет недопустимая исключительная ситуация приведения.

Простые конструкции if / else гораздо легче читать, чем конструкции if / if, и они менее подвержены непредвиденным проблемам, если кто-то попытается перевернуть конструкцию. Давайте возьмем тот же пример на секунду:

if(passwordCheck == false) {
    denyAccess();
}

if(passwordCheck) {
    letThemIn();
}

Смысл взаимоисключающих предложений, которые вы хотите выполнить выше, теряется. Вот что передает конструкция if / else. Две взаимоисключающие ветви исполнения, где всегда будет работать одна из них. Это важная часть безопасности - обеспечение того, чтобы letThemInпосле вашего звонка не было никакого способа denyAccess.

Для ясности кода и обеспечения максимальной защиты критических секций они должны находиться внутри основного предложения ( ifчасти). Неподходящее поведение по умолчанию должно быть в альтернативном предложении ( elseчасть). Например:

if(passwordCheck) {
    letThemIn();
} else {
    denyAccess();
}

ПРИМЕЧАНИЕ: работая с разными языками, я разработал привычку кодирования, которая помогает избежать вопроса "что если это строка?" По сути, это поставить константу на первое место в логическом выражении. Например, вместо проверкиpasswordCheck == false я проверяю false == passwordCheck. Это также позволяет избежать случайной проблемы присваивания, возможной в C ++. Используя этот подход, компилятор будет жаловаться, если я наберу =вместо ==. В таких языках, как Java и C #, компилятор будет рассматривать присвоение в предложении if как ошибку, но C ++ с радостью примет это. Вот почему я также склонен делать нулевую проверку сnull первым.

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

Сказать, что с помощью else при программировании - это плохоotherwise при разговоре - это плохо.

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

Думайте о том, Elseкак белый список вашего приложения потока. Вы проверяете условия, которые ДОЛЖНЫ разрешать продолжение потока приложения, и если они не выполняются, то Elseвыполняется либо решение проблемы, либо прекращение выполнения приложения, либо что-то подобное.

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

Кроме того, что касается вашего заявления о

«Я знаю, что passwordCheck, вероятно, будет логическим значением, но я бы не стал защищать свои приложения».

Для методов, которые вы разрабатываете, ВСЕГДА возвращайте один тип данных. Хотя PHP Core изобилует кодом, который возвращает два или более типов данных, это плохая практика, так как она угадывает вызовы функций. Если вам нужно вернуть более одного типа данных, рассмотрите возможность создания исключения (я считаю, что это часто является причиной, по которой я хотел бы вернуть другой тип данных - что-то пошло ужасно, ужасно неправильно), или рассмотрите возможность реструктуризации вашего кода, чтобы вы могли вернуть только один тип данных.

Прежде всего. ЛОЛ! Theres НИКАКОЙ ПРИЧИНЫ избегать, вообще. Это НЕ плохая практика в любом случае, форма или форма.

Если что-нибудь код должен быть

if(!IsLoggedIn) { ShowBadLoginOrNoAccessPage(); return }

Там нет двух, если там и нет больше. Это то, что я делаю во всех своих приложениях, кроме одного, в котором я выкидываю исключение. Исключение перехватывается в моей функции, которая проверяет URL-адрес для отображения нужной страницы (или, в качестве альтернативы, я могу поместить функцию catch / check в функцию ошибки asp.net). Он распечатывает общую страницу с надписью «не авторизовать» или любым другим сообщением, которое я использую в исключении (я всегда проверяю тип исключения и устанавливаю код состояния http).

- Редактировать - как показано в примере ammoQ два, если это смешно. На самом деле еще так же хорошо или лучше, чем если. Во всяком случае, если нужно избегать ifs (хотя я лично этого не делаю. Но я действительно использую return и много ломаюсь), как было сказано, больше путей кода увеличивают вероятность ошибок. См Цикломатическая Сложность

Редактировать 2 - Если вы беспокоитесь о том, если / еще использование. Также отмечу, что я предпочитаю ставить самый короткий блок кода сверху, например

if(cond == false) {
    a()
    b()
    c()
    onetwothree()
}
else
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}

Скорее тогда

if(cond) 
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}
else
{
    a()
    b()
    c()
    onetwothree()
}

Мне нравится устанавливать по умолчанию до условных, когда я могу. Я чувствую, что это немного легче читать и немного яснее, но это всего лишь предпочтение. У меня есть тенденция, чтобы попытаться избежать негативных условий в моем коде. Я не большой поклонник проверки на! Foo или false == foo, и я чувствую, что else является условным эквивалентом отрицания.

foo = bar;

if ('fubar' == baz) {
    foo = baz;
}

вместо того ...

if ('fubar' == baz) {
    foo = baz;
} else {
    foo = bar;
}

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

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

Как пример, троичные операторы также обычно являются хорошими кандидатами:

If VIP Then 
  Discount = .25
Else
  Discount = 0
End If
Total = (1 - Discount) * Total

Используя троичный подход:

Discount = VIP ? .25 : 0
Total = (1 - Discount) * Total

Тернарные операторы хорошо смещают ветвление вправо.