Что поместить в блок IF, а что - в блок ELSE?

Я предпочитаю первый. Условие должно быть как можно более простым и должно быть достаточно очевидным, что проще - вне условия и!

Я предпочитаю ставить наиболее распространенный путь на первое место, и я твердо верю в сокращение вложенности, поэтому я буду останавливаться, продолжать или возвращаться вместо того, чтобы продолжать, когда возможно. Обычно я предпочитаю проверять на соответствие положительным условиям или инвертировать [и называть] отрицательные условия на положительные.

if (condition)
    return;

DoSomething();

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

Это зависит от вашего потока. Для многих функций я буду использовать предварительные условия:

bool MyFunc(variable) {
    if (variable != something_i_want)
        return false;

    // a large block of code
    // ...
    return true;
}

Если мне нужно что-то делать в каждом случае, я буду использовать формат if (positive_clause) {} else {}.

Для меня это зависит от состояния, например:

if (!PreserveData.Checked)
{  resetfields();}

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

Если код предназначен для проверки состояния ошибки, я предпочитаю сначала помещать этот код, а затем «успешный» код; концептуально это объединяет вызов функции и ее код проверки ошибок, что для меня имеет смысл, потому что они связаны. Например:

  if (!some_function_that_could_fail())
  {
     // Error handling code
  }
  else
  {
     // Success code
  }

Я согласен с Оли в использовании положительного условия if, когда это возможно.

Только, пожалуйста, никогда не делайте этого:

if (somePositiveCondition)
else {
    //stuff
}

Я часто видел это в одном месте, где работал, и задавался вопросом, не понимает ли один из кодеров, как не работает ...

Как правило, если один из них значительно больше другого, я делаю больший блок if.

1. ставь общий путь на первое место
2. превратить отрицательный контроль в положительный (!full == empty)

Я знаю, что это не совсем то, что вы ищете, но ... Многие разработчики используют «защитную оговорку», то есть отрицательный оператор «если», который прерывает работу метода как можно скорее. В этот момент на самом деле нет никакого «другого».

Пример:

if (blah == false)
{
    return; // perhaps with a message
}

// do rest of code here...

Есть некоторые хардкорные ребята из c / C++ / сборки, которые скажут вам, что вы разрушаете свой процессор !!! (во многих случаях процессоры отдают предпочтение «истинному» утверждению и пытаются «предварительно выбрать» следующее, что нужно сделать ... поэтому теоретически любое «ложное» условие очистит канал и будет выполняться на микросекунды медленнее).

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

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

Никогда не называйте переменную not_X, если нужно, воспользуйтесь тезаурусом и найдите противоположное. Я видел много ужасного кода вроде

if (not_dead) {
} else {
}

вместо очевидного

if (alive) {
} else {
}

Затем вы можете разумно использовать (очень читаемый, нет необходимости инвертировать блоки кода)

if (!alive) {
} else {
}

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

if (dead || (!dead && sleeping)) {
} else {
}

Что переводится как

if (dead || sleeping) {
} else {
}

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

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

if TerminatingCondition1 then
  Exit
if TerminatingCondition2 then
  Exit

Теперь мы можем продвигаться к обычным вещам:

if NormalThing then
  DoNormalThing
else
  DoAbnormalThing

Две (противоречивые) цитаты из учебников:

Put the shortest clause of an if/else on top

- Аллен Голуб, «Достаточно веревки, чтобы выстрелить себе в ногу», стр. 52

Put the normal case after the if rather than after the else

- Стив МакКоннелл, «Полный код, 2-е изд.», Стр. 356.

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

Программное обеспечение должно соответствовать тому, что «естественно» для проблемы. Если сомневаетесь, спросите кого-нибудь еще и посмотрите, что люди на самом деле говорят и делают.

А как насчет ситуации, когда "обычным" случаем является бездействие? Что тогда

if ( common ) {
    // pass
}
else {
    // great big block of exception-handling folderol
}

Или ты это делаешь?

if ( ! common ) {
    // great big block of except-handling folderol
}

Правило «всегда позитивно» - это не совсем то, что вам нужно в первую очередь. Вы хотите взглянуть на правила, более похожие на следующие.

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

Если один из двух путей очень короткий (от 1 до 10 строк или около того), а другой намного длиннее, я следую Здесь упоминается правило Голуба и помещаю более короткий фрагмент кода в if. Это упрощает просмотр сценария if / else на одном экране при просмотре кода.

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

Когда я смотрю на проверку данных, я стараюсь внести свои условия в «белый список», то есть я проверяю, что я приму:

if DataIsGood() then
   DoMyNormalStuff
else
   TakeEvasiveAction

Скорее, чем наоборот, которая имеет тенденцию вырождаться в:

if SomeErrorTest then
  TakeSomeEvasiveAction
else if SomeOtherErrorCondition then
  CorrectMoreStupidUserProblems
else if YetAnotherErrorThatNoOneThoughtOf then
  DoMoreErrorHandling
else
  DoMyNormalStuff

Обычно вы можете сделать условие положительным, не переключая блоки if / else.

Изменять

   if (!widget.enabled()) {
     // more common 
   } else {
     // less common 
   }

к

   if (widget.disabled()) {
     // more common 
   } else {
     // less common
   }

Прогнозирование ветвления Intel Pentium предварительно выбирает инструкции для случая «если». Если вместо этого он следует за ветвью «else»: он сбрасывает конвейер команд, вызывая остановку.

Если вас очень волнует производительность: укажите наиболее вероятный результат в предложении if.

Лично я пишу это как

if (expected)
{
   //expected path
}
else
{
   //fallback other odd case
} 

Я всегда ставлю на первое место наиболее вероятное.

В Perl для этого у меня есть дополнительная структура управления. Обратное к if.

unless (alive) {
     go_to_heaven;
} else {
     say "MEDIC";
}

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

С другой стороны, если вы используете такой язык, как Perl, и особенно если ваше ложное условие является либо условием ошибки, либо наиболее распространенным условием, вы можете использовать структуру 'if', которая выполняет блок кода, если условие верно (т.е. противоположно if):

unless ($foo) {
    $bar;
}

Вы всегда должны ставить на первое место наиболее вероятный случай. Помимо того, что он более удобочитаемый, он быстрее. Это также относится к операторам switch.

Я ужасен, когда дело доходит до того, как я настраиваю операторы if. По сути, я настраивал его исходя из того, что именно я ищу, что приводит к тому, что все меняется.
если (userinput = null) {
взорваться насильственно ();
} else {
на самом деле что-то делать;
}

или, возможно, что-то вроде

если (1 + 1 = 2) {
делать вещи;
} else {
взорваться насильственно ();
}

Какая часть оператора if / else действительно что-то делает для меня, - это моя плохая привычка.

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

Итак, предположим, что должно быть предложение «else».

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

1. Чем короче первый блок (блок «if»), тем легче понять всю конструкцию «if-else». Когда блок «if» достаточно длинный, становится слишком легко упустить из виду наличие блока «else».

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

   Опять же, это может быть «если ... нормальный путь ... еще ... ненормальный путь» для всех или «если ... ненормальный путь ... еще ... нормальный путь» для всех, но не быть смесью этих двух вариантов.

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

3. Выражение, которое начинается с отрицания, обычно менее читаемо / понятно, чем выражение, которое этого не делает.

Итак, у нас есть эти три конкурирующих требования / правила, и реальный вопрос: какие из них важнее других. Для Аллена Голуба правило №1, вероятно, является самым важным. Для Стива МакКоннелла - это правило №2. Но я не думаю, что вы действительно можете выбрать только одно из этих правил в качестве единого правила.

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

Мои причины просты:

• Правило №1 безоговорочно, и его невозможно обойти. Если один из блоков настолько длинный, что выходит за пределы экрана - он должен стать блоком «else». (Нет, не рекомендуется создавать функцию / метод механически, просто чтобы уменьшить количество строк в блоке «if» или «else»! Я предполагаю, что в каждом блоке уже есть минимальное количество строк логически оправданный.)

• Правило №2 включает в себя множество условий: несколько конструкций «if-else», все из которых имеют одинаковую асимметрию и т. д. Так что во многих случаях оно просто неприменимо.

  Кроме того, я часто наблюдаю следующий интересный феномен: когда правило №2 действительно применяется и когда оно используется правильно, оно фактически не противоречит правилу №1! Например, всякий раз, когда у меня есть набор операторов «if-else» с асимметрией «нормальный или ненормальный», все «ненормальные» пути короче, чем «нормальные» (или наоборот). Я не могу объяснить этот феномен, но думаю, что это просто признак хорошей организации кода. Другими словами, всякий раз, когда я вижу ситуацию, когда правила №1 и №2 противоречат друг другу, я начинаю искать «запахи кода» и чаще всего их обнаруживаю; а после рефакторинга - тада! нет более болезненного выбора между правилом №1 и правилом №2, :-)

• Наконец, правило № 3 имеет наименьшую область действия и, следовательно, является наименее критичным.

  Кроме того, как здесь отмечают другие коллеги, это правило часто очень легко «обмануть» (например, написать «if (disabled) ,,,» вместо «if (! Enabled) ...»).

Надеюсь, кто-нибудь сможет разобраться в этом опусе ...

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

if (condition)
{
doSomething();
}
else
{
System.out.println("condition not true")
}

Но если для используемого метода условие должно быть ложным, я бы сделал следующее:

if (!condition)
{
doSomething();
}
else
{
System.out.println("condition true");
}