Чи слід, якщо / інші заяви упорядковуються рідкісністю випадків або труднощами їх вирішення?

У якомусь коді я зараз пишу, у мене є щось подібне:

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

Частина мене думає: "Це добре, як це написано. Прості справи повинні йти першими, а складніші справи - далі". Але інша частина говорить: "Ні! elseКод повинен підпадати під дію if, тому що ifце стосується незвичайних справ і 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 false, то потік 1-> 3 (3 втручання)

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

Я виявив, що саме протилежна закономірність призводить до більш легкого для читання коду, а також зменшує або усуває вкладені, якщо заяви. Я позначаю це як «рукавичку». (Розповідаючи історію, рукавиця - це низка завдань, які повинні бути успішно вирішені до завершення остаточного завдання.) Спочатку обробляючи ваші крайові справи , ви дозволяєте основній частині коду бути чистою та стислою:

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

Для мене це більше стосується умов, ніж складності коду, який вони виконують. Упорядкувати потрібно так, щоб спершу вловлювати незвичні умови, а потім - звичайніші. Крім того, якщо інший код дійсно довгий і складний, я, мабуть, зробив додатковий підхід для цього, щоб умовна частина була очевидною для читача.

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

Що стосується таких сценаріїв, то для цього немає правила великого пальця. Але, можливо, ми можемо слідувати, щоб записати позитивний чи найімовірніший код у блоці if та залишити у блоці else або у випадках за замовчуванням.