Нужно ли писать другую часть в каждом условии if?

Ответ 1

Это ужасная идея. Вы получите код формы:

if (something) {
    doSomething();
} else {
}

Как кто-то мог подумать, что более удобочитаемый или поддерживаемый, который не имеет else вообще, находится вне меня. Это звучит как одно из тех правил, которые составляют люди, у которых слишком много свободного времени на руках. Убирайте их так быстро, как можете, или, по крайней мере, уходите спокойно и спокойно: -)

Ответ 2

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

public void DoSomething(string text)
{
    if (text == null)
    {
        throw new ArgumentNullException("text");
    }
    // Do stuff
}

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

Эта модель "раннего выхода" достаточно распространена, по моему опыту, и идет на возвращаемые значения, а также исключения. Я знаю, что есть некоторые, которые предпочитают одну точку возврата из метода, но на языках, с которыми я работаю (Java, С#), которые часто могут привести к значительно менее читаемому коду и более глубокому вложению.

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

public int DoSomething()
{
    // Do some work
    if (conditionBasedOnPreviousWork)
    {
        log.Info("Condition met; returning discount");
        return discount;
    }
    else
    {
        log.Info("Condition not met; returning original price");
        return originalPrice;
    }
}

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

Будет ли это более читаемым без "else"? Это действительно вопрос личного выбора, и я не собираюсь утверждать, что я всегда последователен. Имея одинаковые отступы с одинаковыми отступами, они дают им равный вес - и, возможно, поощряют возможность рефакторинга позже, изменяя условие... тогда как если бы мы только что перешли к "исходной цене возврата", то рефакторинг был помещен в блок if и перемещение случая со скидкой из блока if будет менее явно правильным с первого взгляда.

Ответ 3

Опасность! Опасность, Уилл Робинсон!

http://en.wikipedia.org/wiki/Cargo_cult_programming

Является ли включение пустых блоков else { }, чтобы каким-то образом улучшить качество, читаемость или надежность вашего кода? Думаю, что нет.

Ответ 4

В императивных языках, таких как Java и C, if - else является оператором и не возвращает значение. Поэтому вы можете с радостью написать только часть if и продолжить. И я думаю, что это лучше, чем добавлять пустой else после каждого if.

Однако в функциональных языках, таких как Haskell и Clojure, if - это выражение, и оно должно возвращать значение. Таким образом, это должно быть выполнено с помощью else. Однако все еще есть случаи, когда вам может не понадобиться раздел else. Clojure, для таких случаев имеет макрос when, который обертывает if - else, чтобы возвращать nil в разделе else и избегать его записи.

(when (met? somecondition)
  (dosomething))

Ответ 5

Глядя на это чисто с семантической точки зрения - я не могу придумать ни одного случая где нет никакого неявного else для каждого if.

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

Отличие семантики:

Ответ на этот вопрос зависит от среды, и каков результат ошибки.

Бизнес-код? Сделайте то, что говорят ваши стандарты кодирования.
ИМХО, вы обнаружите, что это исправление, хотя изначально это кажется слишком большой работой, станет бесценным через 10 лет после того, как вы перейдете к этому коду. Но, конечно, это был бы не конец света, если бы вы пропустили важное "анти-условие".

Тем не менее: безопасность, безопасность или жизненный критический код? Это другая история.

В этом случае вы хотите сделать две вещи.
Во-первых: вместо того, чтобы тестировать ошибку, вы хотите доказать, что нет ошибки. Это требует пессимистического представления о входе в любой модуль. Вы считаете, что все неправильно пока вы не докажете, что это правильно.
Второе: в жизни критическая: вы НИКОГДА не хотите причинять боль пациенту.

bool everyThingIsSafe = true;
if(darnThereIsAProblem())
{
   reportToUserEndOfWorld();
}
return everyThingIsSafe;

К сожалению. Я забыл установить everyThingIsSafe false.
Подпрограмма, которая называла этот снипп, теперь лгала. Если бы я инициализировал evertThingIsSafe на false - я всегда в безопасности, но теперь мне нужно предложение else, чтобы указать, что не было ошибки.
И да, я мог бы изменить это на положительный тест, но тогда мне нужно другое для устранения неисправности.
И да, я мог бы назначить everyThingIsSafe() немедленное возвращение чека. И затем проверили флаг, чтобы сообщить о проблеме. Неявное другое, почему бы не быть явным?
Строго говоря, неявное другое это представляет разумное.
Для FDA/аудитора безопасности, возможно, нет.
Если он явный, можно указать на тест, его остальное, и я четко рассмотрел оба условия.

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

Посмотрите на Therac-25. 8 тяжело раненых. 3 мертвых.

Ответ 6

Нет, вам не нужно...

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

Ответ 7

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

if (someCondition)
    bar();
    notbar();  //won't be run conditionally, though it looks like it might

foo();

Я бы написал

 if (someCondition){
        bar();
        notbar();  //will be run
 }
 foo();

Ответ 8

Иногда нет другой части.... и в том числе пустой, просто делает код менее читаемым imho.

Ответ 9

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

Ответ 10

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

В критическом коде обязательно, чтобы каждая ветка учитывалась. Написание другого не требуется, но оставляйте отметку, что еще не нужно и почему. Это поможет рецензенту. Обратите внимание:

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive

Ответ 11

Нет, не нужно писать часть else для оператора if.

Фактически большинство разработчиков предпочитают и рекомендуют избегать блока else.

это

Вместо того, чтобы писать

if (number >= 18) {
    let allow_user = true;
} else {
    let allow_user = false;
}

Большинство разработчиков предпочитают:

let allow_user = false;
if (number >= 18) {
    let allow_user = true;
}