As declarações if / else devem ser organizadas pela conscientização dos casos ou pela dificuldade de lidar com eles?

Em algum código que estou escrevendo agora, tenho algo parecido com isto:

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

Parte de mim pensa: "Está tudo bem do jeito que está escrito. Casos simples devem ser os primeiros e casos mais complicados devem ser os próximos." Mas outra parte diz: "Não! O elsecódigo deve ficar abaixo do if, porque ifé para lidar com casos incomuns e elsepara todos os outros casos". Qual é correto ou preferível?

Ordem pela probabilidade de serem executadas. As condições mais comuns, mais prováveis ​​etc. devem ser as primeiras.

A "dificuldade de lidar com eles" deve ser tratada pela estrutura de código, abstração etc. no exemplo, o bloco else pode ser refatorado para chamada de método único. Você deseja que suas ifcláusulas estejam no mesmo nível abstrato.

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

Tente melhorar a legibilidade. Uma maneira é colocar o bloco de código mais longo na parte else.

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

é mais legível do que

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

Nenhuma regra fixa, como tal, ouvi falar sobre o uso, mas sigo assim

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

Mas se ambos tiverem a mesma função com propriedades diferentes, é melhor optar por algo incomum primeiro do que o habitual, para que você possa salvar uma instrução.

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

Para o código de montagem acima, o código será algo como isto:

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 a condição interna se for verdadeira, o fluxo será 1-> 2 (4 intruções)
Se a condição interna for falsa, o fluxo será 1-> 3 (3 intruções)

Portanto, é melhor colocar eventos incomuns ou que ocorrem raramente, caso sejam parte e condição normal, para que possamos salvar uma instrução toda vez ;-)

Descobri que o padrão oposto exato leva a uma leitura mais fácil do código e reduz ou elimina instruções if aninhadas. Eu me refiro a isso como um padrão de "manopla". (Na narração de histórias, uma luva seria uma série de desafios que precisam ser enfrentados com êxito antes que a tarefa final seja concluída.) Ao lidar com seus casos extremos primeiro , você permite que o corpo principal do seu código seja limpo 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

Para mim, é mais sobre as condições do que sobre a complexidade do código que eles executam. Você precisa solicitar as condições para capturar primeiro condições incomuns, depois as mais comuns depois. Além disso, se o código else for realmente longo e complicado, eu provavelmente faria um sub para isso, para manter a parte condicional óbvia para o leitor.

Eu não tenho uma regra fixa, mas geralmente eu a sigo - primeiro, considere onde há um padrão de design ausente que levará isso em consideração. Caso contrário, escrevo para que a condição no if seja a mais claramente compreendida. Ou seja, evitando duplos negativos e similares.

Quanto a esses cenários, não existe uma regra geral. Mas, possivelmente, podemos seguir para escrever o código positivo ou mais provável no bloco if e deixar de fora no bloco else ou nos casos padrão.