Les déclarations if / else devraient-elles être organisées en fonction de la rareté des cas ou de la difficulté de les traiter?

Dans un code que j'écris en ce moment, j'ai quelque chose comme ceci:

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

Une partie de moi pense que "c'est bien la façon dont c'est écrit. Les cas simples devraient aller en premier et les cas plus compliqués devraient aller ensuite." Mais une autre partie dit: "Non! Le elsecode devrait aller sous le if, parce qu'il ifest pour traiter des cas inhabituels et elsepour tous les autres cas." Qu'est-ce qui est correct ou préférable?

Ordre par leur probabilité d'être exécuté. La ou les conditions les plus courantes, les plus probables, etc. doivent apparaître en premier.

La "difficulté de les traiter" devrait être traitée par la structure du code, l'abstraction, etc. dans l'exemple, le bloc else pourrait être refactorisé en appel de méthode unique. Vous voulez que vos ifclauses soient au même niveau abstrait.

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

Essayez d'améliorer la lisibilité. Une façon consiste à placer le bloc de code plus long dans la partie else.

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

est plus lisible que

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

Pas de règle fixe en tant que telle j'ai entendu parler de l'usage mais je suis comme ça

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

Mais si les deux ont la même fonction avec des propriétés différentes, il vaut mieux opter d'abord pour inhabituel puis habituel afin de pouvoir enregistrer une instruction.

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

Pour le code d'assemblage ci-dessus, le code ressemblera à ceci:

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 condition à l'intérieur de if est vraie, le débit est 1-> 2 (4 intructions)
SI la condition à l'intérieur de if est fausse, alors le flux est 1-> 3 (3 intructions)

Il est donc préférable de mettre des événements inhabituels ou rarement survenant dans une partie et un état normal ailleurs afin que nous puissions enregistrer une instruction à chaque fois ;-)

J'ai trouvé que le modèle opposé exact conduit à un code plus facile à lire et réduit ou élimine les instructions if imbriquées. J'appelle cela un modèle de «gantelet». (Dans le récit, un gant serait une série de défis qui doivent être relevés avec succès avant que la tâche finale ne soit terminée.) En traitant d'abord vos cas marginaux , vous permettez au corps principal de votre code d'être propre et concis:

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

Pour moi, il s'agit plus des conditions que de la complexité du code qu'elles exécutent. Vous devez ordonner les conditions afin de piéger les conditions inhabituelles en premier, puis les plus courantes après. De plus, si le code else est vraiment long et compliqué, je ferais probablement un sub pour cela, pour garder la partie conditionnelle évidente pour le lecteur.

Je n'ai pas de règle fixe, mais en général, je suis la suivante - tout d'abord, réfléchissez à l'endroit où il y a un modèle de conception manquant qui prendra cela en compte. Sinon, je l'écris pour que la condition dans le if soit la plus clairement comprise. Autrement dit, en évitant les doubles négatifs et similaires.

Quant à de tels scénarios, il n'y a pas de règle empirique pour cela. Mais nous pouvons éventuellement suivre pour écrire le code positif ou le plus probable dans le bloc if et laissé de côté dans le bloc else ou les cas par défaut.