Подтвердить что ты не робот

Должно ли выражение "если" всегда иметь "else"?

Это может быть религиозный аргумент, но в моей работе обсуждался ad-nauseum, должны ли все утверждения IF включать предложение ELSE, даже если предложение ELSE содержит комментарий, в котором говорится, что он был "намеренно оставлен пустым",.

Я слышал аргументы для обеих сторон: Лагерь "Для" - гарантирует, что коды действительно решали, требует ли условие условие ELSE Код "Против" лагеря сложнее читать, добавляет слишком много шума

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

Благодарим вас за помощь.

Кстати: я искал StackOverflow для ответа на этот вопрос и не смог его найти. Если он есть, просто включите ссылку и закройте. Спасибо.

4b9b3361

Ответ 1

Кажется, что мне бесполезно печатать... и возможную причину путаницы. Если вам это не нужно, не ставьте его!

Ответ 2

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

Ответ 3

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

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

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

Удачи.

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

Я склонен использовать инструкции "раньше, если" как средство снижения уровня вложенных фигурных скобок (или отступов в 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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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 DELAY...

Ответ 13

Haskell if всегда тройной. Так что обязательное условие.

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

поэтому после этого вы не должны писать else.

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

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

Ответ 18

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

Выполнение

if(foo){
    bar
}

вместо

if(foo)
    bar

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

if(foo)
    bar
    dot

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