¿Deberían las declaraciones if / else ser organizadas por la rareza de los casos o la dificultad de tratar con ellos?

En algún código que estoy escribiendo ahora, tengo algo como esto:

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

Una parte de mí piensa: "Está bien la forma en que está escrito. Los casos simples deberían ir primero y los casos más complicados deberían ir después". Pero otra parte dice: "¡No! El elsecódigo debe ir debajo de if, porque ifes para tratar casos inusuales y elsees para tratar todos los demás casos". ¿Cuál es correcto o preferible?

Orden por su probabilidad de ser ejecutado. La (s) condición (es) más común (s), más probable (s) debe ir primero.

La "dificultad de tratar con ellos" debe abordarse mediante la estructura del código, la abstracción, etc. En el ejemplo, el bloque else podría refactorizarse a la llamada a un solo método. Desea que sus ifcláusulas estén en el mismo nivel abstracto.

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

Intenta mejorar la legibilidad. Una forma es colocar el bloque de código más largo en la parte else.

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

es más legible que

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

Ninguna regla fija como tal escuché sobre el uso, pero sigo así

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

Pero si ambos tienen la misma función con propiedades diferentes, entonces mejor optar por lo inusual primero que lo habitual para que pueda guardar una instrucción.

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

Para el código de ensamblaje de código anterior será algo como esto:

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:

Si la condición interna es verdadera, entonces el flujo es 1-> 2 (4 instrucciones)
SI la condición interna es falsa, entonces el flujo es 1-> 3 (3 instrucciones)

Por lo tanto, es mejor poner eventos inusuales o que ocurren raramente en una condición parcial y normal en otra cosa para que podamos guardar una instrucción cada vez ;-)

He descubierto que el patrón opuesto exacto conduce a un código más fácil de leer y reduce o elimina las instrucciones anidadas if. Me refiero a esto como un patrón de "guantelete". (En la narración de cuentos, un guante sería una serie de desafíos que deben cumplirse con éxito antes de que se complete la tarea final). Al manejar sus casos límite primero , permite que el cuerpo principal de su código sea limpio y 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

Para mí, se trata más de las condiciones que de la complejidad del código que ejecutan. Debe ordenar las condiciones para atrapar primero las condiciones inusuales, luego las más comunes después. Además, si el código else es realmente largo y complicado, probablemente haría un sub para eso, para mantener la parte condicional obvia para el lector.

No tengo una regla fija, pero generalmente sigo esto: primero, considere dónde hay un patrón de diseño perdido que lo tendrá en cuenta. Si no, lo escribo para que la condición en el if sea la más clara. Es decir, evitar los dobles negativos y similares.

En cuanto a tales escenarios, no hay una regla general para ello. Pero posiblemente podamos seguir para escribir el código positivo o más probable en el bloque if y dejarlo fuera en el bloque else o en los casos predeterminados.