Должны ли / или другие утверждения быть организованы редкостью случаев или трудностью иметь дело с ними?

В некотором коде, который я пишу прямо сейчас, у меня есть что-то вроде этого:

if (uncommon_condition) {
    do_something_simple();
} else {
    do();
    something();
    long();
    and();
    complicated();
}

Часть меня думает: «Все хорошо, как написано. Сначала должны идти простые дела, а затем более сложные дела». Но другая часть говорит: «Нет! elseКод должен идти под if, потому что ifпредназначен для работы с необычными случаями и elseдля решения всех других случаев». Что является правильным или предпочтительным?

Порядок по их вероятности быть выполненным. Наиболее распространенные, наиболее вероятные и т. Д. Условия должны идти первыми.

«Сложность обращения с ними» должна решаться с помощью структуры кода, абстракции и т. Д. В примере блок else может быть реорганизован для вызова одного метода. Вы хотите, чтобы ваши ifпредложения были на одном абстрактном уровне.

if ( ! LotteryWinner ) {
    GoToWorkMonday();
} else {
    PlanYearLongVacation();
}

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

if (s == null)
     // short code
else 
     // long 
     // code
     // block

более читабельно, чем

if (s != null)
    // long
    // code
    // block
else
    // short code

Нет фиксированного правила как такового, я слышал об использовании, но я следую так

if(usual)
{
(more often)
}
else (unusual)
{
(rarely occurring)
}

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

if(x == 0)  // 1
  {x = 1;}  // 2
else
  {x = 2;}  // 3

Для приведенного выше кода ассемблерный код будет примерно таким:

1. 000d 837DFC00        cmpl    $0, -4(%ebp)
   0011 7509            jne .L2

2. 0013 C745FC01        movl    $1, -4(%ebp)
   001a EB07            jmp .L3

    .L2:
3.001c C745FC02         movl    $2, -4(%ebp)

        .L3:

Если условие внутри if истинно, то поток равен 1-> 2 (4 операции).
Если условие внутри if ложно, то поток равен 1-> 3 (3 операции).

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

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

if(gauntlet_1){ handle the first gauntlet condition }; 
if(gauntlet_2){ handle the second gauntlet condition };
...
// All preconditions (gauntlets) have been successfully handled

// Perform your main task here

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

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

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