Нужно ли писать еще часть в каждом условии if?

Question

Вопрос, который я задал, может быть закрыт. Но я просто хочу знать, что нужно писать еще часть каждого условия if. Один из моих старших программистов сказал мне, что «вы должны написать еще часть в каждом условии». Предположим, что у нас нет условия для записи в другой части, что мы должны делать? Я предполагаю, что здоровая дискуссия здесь происходит ....

Благодарности & С уважением, Рахул Виас

Answer 1

Это ужасная идея. Вы в конечном итоге с кодом вида:

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

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

Answer 2

Нет, вы не должны ..

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

Answer 3

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

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

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

Answer 4

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

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

foo(); 

Я бы написать

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

Answer 5

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

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

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

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

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

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, на первый взгляд будет менее правильным.

Answer 6

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

Answer 7

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

Answer 8

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

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

(when (met? somecondition) 
    (dosomething)) 

Answer 9

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

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

Семантика в стороне:

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

Код предприятия? Сделайте то, что говорят ваши стандарты кодирования.
IMHO вы обнаружите, что это исправление, хотя изначально это кажется слишком большой работой, станет бесценным через 10 лет после того, как вы пересмотрите этот код. Но, конечно, это был бы не конец света, если бы вы пропустили важное «анти-условие».

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

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

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

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

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

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

Answer 10

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

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

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