Общее программирование - иначе или для ясности

В ситуации, когда переменная может иметь два разных значения, и вы делаете что-то, если ее одно, что-то другое, если другое, вы бы просто сделали:

if(myVariable == FIRST_POSSIBLE_VALUE) { ... }
else { ... }

или вы бы сделали:

if(myVariable == FIRST_POSSIBLE_VALUE) { ... }
else if (myVariable == SECOND_POSSIBLE_VALUE) { ... }

для ясности, в ситуации, когда читатель не обязательно сможет сказать, что он делает то же самое (но в другом случае, если выражение "ненужное")? Так что бы вы сделали? Спасибо!

РЕДАКТИРОВАТЬ: Существует на самом деле гораздо больше различных вариантов для чего-то вроде этого: троичный оператор, если-еще, если-еще, если-еще-еще, -if-еще (с утверждением), переключатель. У каждого есть свое место, но его трудно решить..

9 ответов

Решение

Разве это не то, что assert был сделан для?

if (condition1) { ... }
else { assert(condition2); }

Это может быть расширено и для логики трех состояний.

if (condition1) { ... }
elsif (condition2) { ... }
else { assert(condition3); }

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

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

if(color==red){
....
}else{ //our theme only allows for red and yellow, so the color must be yellow.
....
}

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

Я никогда не делаю что-то подобное

if(file.is_open==1){
....
}else if(file.is_open==0){
....

}

Поскольку is_open является логическим значением, бессмысленно указывать, что, поскольку единственная оставленная опция - это 0, это также может сэкономить немного времени на ввод текста, когда вы должны реорганизовать код для использования вместо него is_open(), так как теперь вы должны изменить только одну строку вместо двух.

и операторы "else if", которые, на мой взгляд, следует переключать на переключатели, если их больше 1 "else if", если, конечно, язык не делает это невозможным (например, как C не может обрабатывать строки в переключателях)

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

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

Я использую if-else только для логических проверок, это означает, что если выражение не совпадает, может быть только else. Или я хочу взять все с остальным: думать об этом как по умолчанию.

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

В Java невозможно использовать переключатель для строк. Таким образом, вы можете использовать что-то вроде этого:

if(string.equals("foo")) {
    // first case
} else if(string.equals("bar")) {
    // second case
} else {
    throw IllegalArgumentException(" ... ");
    // or log it
}

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

Когда ваши входные данные могут быть четко разделены на отдельные случаи, я чувствую, что в основном лучше явно указать, что это за случаи, например, если вы ожидаете, что 'n' будет числом от 0 до 100, и у вас есть 3 случая:

if (n >= 0 && n < 30) {
   case1();
} else if (n >=30 && n < 70) {
   case2();
} else if (n >=70 && n < 100) {
   case3();
}

в некоторых случаях случай 'else' хорош для проверки ошибок

} else {
   error("n should be between 0 and 100");
}

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

} else { // (n >= 70 && n < 100)
   case3();
}

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

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

if (p == NULL) {
   doSomething();
} else {
   doSomethingElse();
}

... оправдано тем фактом, что очень очевидно и неявно с первого условия if, для чего используется другое.

Иногда условие утверждения else очень очевидно. Например

if(user.IsNew) { } else { /*in this case user.IsNew != true*/ }

Но в некоторых других случаях иное не так очевидно, и лучше уточнить условие else. Это также больше в будущем, если будут добавлены другие возможные условия.

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

if(user.SelectedStyle == Styles.Red) {
} else if(user.SelectedStyle == Styles.Basic) {
} else {
 throw new Exception("Not implemented");
}

В приведенном выше случае новый стиль (например, Style.Blue) заставит ваше приложение выдать исключение.

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

Если булевы тесты одного типа, лучше использовать оператор switch.

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

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

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

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

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

Другие вопросы по тегам