Devrais-je suivre le chemin normal ou échouer tôt?

La citation suivante est extraite du livre Code Complete :

"Mettez le cas normal après le ifplutôt que après le else"

Ce qui signifie que des exceptions / déviations par rapport au chemin standard doivent être mises en place else.

Mais le programmeur pragmatique nous apprend à "planter tôt" (p. 120).

Quelle règle devrais-je suivre?

"Crash early" n'indique pas quelle ligne de code est textuelle avant. Il vous indique de détecter les erreurs lors de la première étape du traitement , de manière à ne pas prendre par inadvertance de décisions et de calculs basés sur un état déjà défaillant.

Dans une construction if/ else, seul l'un des blocs est exécuté. Par conséquent, on ne peut pas dire qu'aucun d'entre eux constitue une étape "antérieure" ou "ultérieure". Comment les commander est donc une question de lisibilité, et "échouer tôt" n'entre pas dans la décision.

Si votre elseinstruction ne contient que du code d'échec, alors, très probablement, elle ne devrait pas être là.

Au lieu de faire ceci:

if file.exists() :
  if validate(file) :
    # do stuff with file...
  else :
    throw foodAtMummy
else :
  throw toysOutOfPram

fais ça

if not file.exists() :
  throw toysOutOfPram

if not validate(file) :
  throw foodAtMummy

# do stuff with file...

Vous ne voulez pas imbriquer profondément votre code simplement pour inclure la vérification des erreurs.

Et, comme tout le monde l’a déjà dit, les deux conseils ne sont pas contradictoires. L'une concerne l' ordre d'exécution , l'autre l'ordre de code .

Vous devriez suivre les deux.

Le conseil "Crash early" / fail early signifie que vous devez tester vos entrées pour rechercher d'éventuelles erreurs le plus rapidement possible.
Par exemple, si votre méthode accepte une taille ou un nombre censé être positif (> 0), le conseil d'échec précoce signifie que vous testez cette condition dès le début de votre méthode, au lieu d'attendre que l'algorithme produise un non-sens. résultats.

Le conseil de mettre le cas normal en premier signifie que si vous testez une condition, le chemin le plus probable doit venir en premier. Cela contribue aux performances (car la prédiction de branche du processeur sera exacte plus souvent) et à la lisibilité, car vous n'avez pas à ignorer des blocs de code lorsque vous essayez de comprendre ce que la fonction fait dans les cas normaux.
Ce conseil ne s'applique pas vraiment lorsque vous testez une condition préalable et que vous effectuez une sauvegarde immédiate (à l'aide d'assertions ou de if (!precondition) throwconstructions), car il n'y a pas de gestion d'erreur à ignorer lors de la lecture du code.

Je pense que @JackAidley en a déjà dit l'essentiel , mais laissez-moi le formuler comme suit :

sans exceptions (par exemple C)

Dans le flux de code normal, vous avez:

if (condition) {
    statement;
} else if (less_likely_condition) {
    less_likely_statement;
} else {
    least_likely_statement;
}
more_statements;

Dans le cas «erreur sur tôt», votre code lit tout à coup:

/* demonstration example, do NOT code like this */
if (condition) {
    statement;
} else {
    error_handling;
    return;
}

Si vous voyez ce modèle - un returndans un else(ou même ifbloc), retravailler immédiatement si le code en question ne pas avoir un elsebloc:

/* only code like this at University, to please structured programming professors */
function foo {
    if (condition) {
        lots_of_statements;
    }
    return;
}

Dans le monde réel…

/* code like this instead */
if (!condition) {
    error_handling;
    return;
}
lots_of_statements;

Cela évite les imbrications trop profondes et remplit le cas de «rupture précoce» (aide à garder l'esprit et le flux de code propres) et ne viole pas la «mise de la chose la plus probable dans la ifpièce», car il n'y a tout simplement aucune elsepartie .

C et nettoyage

Inspiré par une réponse à une question similaire (qui s’est mal compris), voici comment vous effectuez le nettoyage avec C. Vous pouvez utiliser un ou deux points de sortie, voici un pour deux points de sortie:

struct foo *
alloc_and_init(size_t arg1, int arg2)
{
    struct foo *res;

    if (!(res = calloc(sizeof(struct foo), 1)))
        return (NULL);

    if (foo_init1(res, arg1))
        goto err;
    res.arg1_inited = true;
    if (foo_init2(&(res->blah), arg2))
        goto err;
    foo_init_complete(res);
    return (res);

 err:
    /* safe because we use calloc and false == 0 */
    if (res.arg1_inited)
        foo_dispose1(res);
    free(res);
    return (NULL);
}

Vous pouvez les réduire en un point de sortie s'il y a moins de nettoyage à faire:

char *
NULL_safe_strdup(const char *arg)
{
    char *res = NULL;

    if (arg == NULL)
        goto out;

    /* imagine more lines here */
    res = strdup(arg);

 out:
    return (res);
}

Cette utilisation de gotoest parfaitement bien, si vous pouvez vous en occuper; Le conseil de ne pas utiliser gotoest destiné aux personnes qui ne peuvent pas encore décider par elles-mêmes si une utilisation est bonne, acceptable, mauvaise, code spaghetti ou autre chose.

Exceptions

Ce qui précède parle de langues sans exceptions, ce que je préfère vraiment (je peux utiliser la gestion explicite des erreurs beaucoup mieux et avec beaucoup moins de surprise). Pour citer igli:

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.
<mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

Mais voici une suggestion pour savoir comment le faire dans une langue avec des exceptions et quand vous voulez bien l'utiliser:

erreur de retour face aux exceptions

Vous pouvez remplacer la plupart des premiers temps returnpar une exception. Cependant , votre flux de programme normal , c’est-à-dire tout flux de code dans lequel le programme n’a pas rencontré, eh bien, une exception… une condition d’erreur ou une telle erreur ne doit pas déclencher d’exception.

Cela signifie que…

# this page is only available to logged-in users
if not isLoggedIn():
    # this is Python 2.5 style; insert your favourite raise/throw here
    raise "eh?"

… Ça va, mais…

/* do not code like this! */
try {
    openFile(xyz, "rw");
} catch (LockedException e) {
    return "file is locked";
}
closeFile(xyz);
return "file is not locked";

… n'est pas. Fondamentalement, une exception n'est pas un élément de flux de contrôle . Cela rend également les opérations étranges («ces programmeurs Java ™ nous disent toujours que ces exceptions sont normales») et peuvent entraver le débogage (par exemple, demander à l'EDI d'interrompre toute exception). Les exceptions nécessitent souvent que l'environnement d'exécution décompresse la pile pour produire une trace, etc. Il existe probablement d'autres raisons.

Cela revient à: dans un langage prenant en charge les exceptions, utilisez ce qui correspond à la logique et au style existants et vous semble naturel. Si vous écrivez quelque chose à partir de zéro, faites-le d’accord tôt. Si vous écrivez une bibliothèque à partir de zéro, pensez à vos consommateurs. (N'utilisez jamais non plus abort()dans une bibliothèque…). Mais quoi que vous fassiez, en règle générale, aucune exception n'est levée si l'opération se poursuit (plus ou moins) normalement après.

conseils généraux Exceptions

Essayez d’obtenir l’utilisation en premier lieu des exceptions approuvées par toute l’équipe de développement. Fondamentalement, planifiez-les. Ne les utilisez pas en abondance. Parfois, même en C ++, Java ™, Python, un retour d'erreur est préférable. Parfois ce n'est pas; utilisez-les avec pensée.

À mon avis, la "condition de garde" est l’un des moyens les plus simples et les plus faciles de rendre le code lisible. Je déteste vraiment quand je vois ifau début de la méthode et ne vois pas le elsecode car il est hors de l'écran. Je dois faire défiler juste pour voir throw new Exception.

Placez les vérifications au début de sorte que la personne qui lit le code ne soit pas obligée de sauter partout dans la méthode pour le lire, mais au contraire de toujours le scanner de haut en bas.

(La réponse de @mirabilos est excellente, mais voici comment je réfléchis à la question pour parvenir à la même conclusion :)

Je pense à moi-même (ou à quelqu'un d'autre) en train de lire le code de ma fonction plus tard. Lorsque je lis la première ligne, je ne peux faire aucune hypothèse à propos de mon entrée (sauf celles que je ne vérifierai pas de toute façon). Donc, ma pensée est "Ok, je sais que je vais faire des choses avec mes arguments. Mais d'abord, nettoyons-les", c'est-à-dire supprimons les chemins de contrôle dans lesquels ils ne me plaisent pas. "Mais en même temps , Je ne vois pas le cas normal comme quelque chose qui est conditionné; je tiens à souligner que cela est normal.

int foo(int* bar, int baz) {

   if (bar == NULL) /* I don't like you, leave me alone */;
   if (baz < 0) /* go away */;

   /* there, now I can do the work I came into this function to do,
      and I can safely forget about those if's above and make all 
      the assumptions I like. */

   /* etc. */
}

Ce type de classement dépend de la criticité de la section de code en question et de l’existence éventuelle de valeurs par défaut.

En d'autres termes:

A. section critique et pas de valeurs par défaut => Fail Early

B. section non critique et valeurs par défaut => Utiliser les valeurs par défaut dans la partie else

C. entre cas => décider au cas par cas