Se le dichiarazioni / else dovessero essere organizzate per rarità di casi o difficoltà nel trattarli?

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

La "difficoltà di trattare con loro" dovrebbe essere trattata dalla struttura del codice, dall'astrazione, ecc. nell'esempio il blocco else potrebbe essere rifatto su una singola chiamata di metodo. Vuoi che le tue clausole if siano allo stesso livello astratto.

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

Cerca di migliorare la leggibilità. Un modo è quello di 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 poi al solito, in modo da poter salvare un'istruzione.

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

Per il codice di assembly del codice sopra sarà qualcosa di simile a questo:

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 interna è vera, il flusso è 1- > 2 (4 intruzioni)
Se la condizione interna è falsa, il flusso è 1- > 3 (3 istruzioni)

Quindi è meglio mettere eventi insoliti o di rado in caso di condizione parziale e normale in altrimenti, in modo da poter salvare un'istruzione ogni volta; -)

Ho scoperto che il modello esatto opposto porta a un codice più semplice da leggere e riduce o elimina le istruzioni nidificate if. Mi riferisco a questo come un modello "guanto di sfida". (Nel raccontare storie, una sfida sarebbe una serie di sfide che devono essere soddisfatte con successo prima che l'attività finale sia completata.) Gestendo i casi limite prima , permetti al corpo principale del tuo 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 è più sulle condizioni che sulla complessità del codice che eseguono. Devi ordinare le condizioni in modo da intrappolare prima le condizioni insolite, poi le più comuni dopo. Inoltre, se il codice else è davvero lungo e complicato, probabilmente farei un sottotitolo per questo, per mantenere la parte condizionale ovvia per il lettore.

Non ho una regola fissa, ma di solito seguo questa regola - innanzitutto, considera dove c'è un modello di progettazione mancante che lo terrà presente. Altrimenti, lo scrivo in modo tale che la condizione nel caso sia la più chiara. Cioè, evitando doppi negativi e simili.

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