Le dichiarazioni if ​​/ else dovrebbero essere organizzate in base alla rarità dei casi o alla difficoltà di affrontarli?

In alcuni codici che sto scrivendo proprio ora, ho qualcosa del genere:

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

Una parte di me pensa "Va bene il modo in cui è scritto. I casi semplici dovrebbero andare prima e quelli più complicati dovrebbero andare dopo". Ma un'altra parte dice: "No! Il elsecodice dovrebbe andare sotto il if, perché ifè per gestire casi insoliti ed elseè per gestire tutti gli altri casi." Qual è corretto o preferibile?

Ordina per la loro probabilità di essere giustiziati. Le condizioni più comuni, più probabili, ecc. Dovrebbero andare per prime.

La "difficoltà di gestirli" dovrebbe essere affrontata dalla struttura del codice, dall'astrazione, ecc. Nell'esempio il blocco else potrebbe essere refactored alla singola chiamata di metodo. Volete che le vostre ifclausole siano allo stesso livello astratto.

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

Cerca di migliorare la leggibilità. Un modo è posizionare il blocco di codice più lungo nella parte else.

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

è più leggibile di

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

Nessuna regola fissa in quanto tale ho sentito parlare dell'uso ma seguo così

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

Ma se entrambi hanno la stessa funzione con proprietà diverse, allora è meglio andare prima inusuali prima del solito in modo da poter salvare un'istruzione.

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

Per il codice di assemblaggio sopra il codice sarà qualcosa del genere:

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:

Se la condizione dentro è vera, allora il flusso è 1-> 2 (4 istruzioni)
SE la condizione dentro è falsa, allora il flusso è 1-> 3 (3 istruzioni)

Quindi è meglio mettere eventi insoliti o che si verificano raramente in parte e in condizioni normali in modo da poter salvare un'istruzione ogni volta ;-)

Ho scoperto che l'esatto modello opposto porta a una lettura più semplice del codice e riduce o elimina le istruzioni if ​​annidate. Mi riferisco a questo come a un modello "guanto". (Nel racconto di storie, un guanto sarebbe una serie di sfide che devono essere affrontate con successo prima che il compito finale sia completato.) Gestendo prima i casi limite , si consente al corpo principale del codice di essere pulito e conciso:

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

Per me si tratta più delle condizioni che della complessità del codice che eseguono. È necessario ordinare le condizioni in modo da intrappolare prima le condizioni insolite, quindi quelle più comuni dopo. Inoltre, se il codice else è davvero lungo e complicato, probabilmente farei un sub per questo, per mantenere ovvia la parte condizionale per il lettore.

Non ho una regola fissa, ma generalmente seguo questo: prima di tutto, considera dove c'è un modello di progettazione mancato che lo terrà conto. In caso contrario, lo scrivo in modo che la condizione in if sia la più chiaramente compresa. Cioè, evitando doppi negativi e simili.

Per quanto riguarda tali scenari, non esiste una regola per il pollice. Ma forse possiamo seguire per scrivere il codice positivo o più probabile nel blocco if e tralasciato nel blocco else o nei casi predefiniti.