Должен, 'если' оператор всегда 'еще' имеет пункт? [закрытый]

есть много «слов», указывающих путь к программированию, например DRY

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

так что после этого вам не следует ' вот запрошенные вами ссылки: http://en.wikipedia.org/wiki/YAGNI http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи.

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

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

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

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

Haskell's 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. Я не думаю, что это выгодно иметь предложение о жизни на языках высокого уровня ... черт возьми, даже в сборке! Идея есть: если вы проверили и не прыгли, то условие было ложно, и мы можем продолжать. Делает логическое значение для меня ...

Редактировать: Проверьте эту статью, чтобы увидеть, почему остальные пункты не имеют большого значения: http://www.codinghorror.com/blog/2006/01/flatting-arrow-code.html

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

чтобы расширить (полностью корректный) ответ J.J., библиотека protobuf не имеет никакого способа проработать, как долго сообщения сами по себе, или выяснить, какой тип объекта protobuf отправляется *. Так что другое приложение, которое отправляет вам данные, должно уже делать что-то подобное.

Когда мне пришлось это сделать, я реализовал таблицу поиска:

messageLookup={0:foobar_pb2.MessageFoo,1:foobar_pb2.MessageBar,2:foobar_pb2.MessageBaz}

... и сделал по существу то, что сделал Джей Джей, но у меня также была вспомогательная функция:

    def parseMessage(self,msgType,stringMessage):
        msgClass=messageLookup[msgType]
        message=msgClass()
        message.ParseFromString(stringMessage)
        return message

... которую я вызвал, чтобы превратить последовательность в объект протобуфа.

(*) Я думаю, что можно обойти это, инкапсулируя конкретные сообщения в сообщение контейнера

Любой статический код анализа (например, PC-Lint ) должен быть в состоянии сообщить вам об этом. Для PC-Lint, я знаю, что это так.

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

Выполнение

if(foo){
    bar
}

вместо

if(foo)
    bar

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

if(foo)
    bar
    dot

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

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

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