Должен ли оператор " if "всегда иметь предложение "else"? [закрытый]

нет. Если вам не нужно запускать какой-либо код на else боковая, вам не нужно else предложения.

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

похоже, что вы не старший человек в этом сценарии, поэтому вы не можете просто решить, что это так. Я предлагаю попросить" пустые другие " стороны показать, где такой процесс предлагается в книге (блоги не в счет) О развитии. А еще лучше, в 3 книгах о развитии. Я прочитал свою долю книг по программированию на разных языках программирования с 1982 года, и я никогда не видел такого предложения.

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

удачи.

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

вы говорите о языках, производных от Алгола?

в Lisp я бы сказал Да: каждый, если должен иметь предложение else. В противном случае, вы должны использовать, когда.

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

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

Я склонен использовать операторы "early if" в качестве средства снижения уровня вложенных фигурных скобок (или отступов в Python) следующим образом:

if (inParam == null) {
  return;
}

if (inParam.Value < 0) {
  throw new ArgumentException(...,...);
}
// Else ... from here on my if statements are simpler since I got here.

конечно, .Net версии 4.0, теперь имеет контракты кода, который является большим! Но в большинстве языков этого еще нет, поэтому "ранние ifs" (за неимением лучшего термина) велики именно потому, что они устраняют ряд других предложений и вложенных ifs. Я не думаю, что полезно иметь предложение else на языках высокого уровня ... черт возьми, даже в собрание! Идея такова: если вы проверили и не прыгать, то условие было ложным, и мы можем продолжать. Имеет логический смысл для меня ...

EDIT: проверьте эту статью, а также посмотреть, почему else предложения не очень помогают: http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html

"гарантирует, что коды есть на самом деле решается ли условие требуется предложение ELSE"

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

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

if (thereIsSomeThingToDoInTheElse)
{
    putAnElseClause();
}
else
{
    // intentionally left blank
}

SQL Server 2000, 2005 по крайней мере.

IF 1 = 1
BEGIN
    PRINT 'doing something productive'
END
ELSE
BEGIN
    --Just sitting here
END


Msg 102, Level 15, State 1, Line 8
Incorrect syntax near 'END'.

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

Если Хаскелла всегда троичный. Так что остальное обязательно.

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

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

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

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

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

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

есть много "слов", говорящих вам путь к программированию, таких как DRY

в этом случае я бы использовал YAGNI.. тебе это не понадобится..

Итак, после этого вы не должны писать еще.

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

изменить: вот ссылки, которые вы запрошенный: http://en.wikipedia.org/wiki/YAGNI http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

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

делаешь

if(foo){
    bar
}

вместо

if(foo)
    bar

может в конечном итоге предотвратить

if(foo)
    bar
    dot

Я действительно не могу придумать ни одного языка, который я знаю, где опуская ненужное другое может привести к потенциальным ошибкам :-?