Devo seguire il percorso normale o fallire presto?

Dal libro Code Complete arriva la seguente citazione:

"Metti il ​​caso normale dopo il ifpiuttosto che dopo il else"

Ciò significa che nel elsecaso dovrebbero essere previste eccezioni / deviazioni dal percorso standard .

Ma The Pragmatic Programmer ci insegna a "schiantarci presto" (p. 120).

Quale regola dovrei seguire?

"Arresto anomalo" non riguarda la linea di codice che precede testualmente. Ti dice di rilevare errori nella prima fase possibile dell'elaborazione , in modo da non prendere inavvertitamente decisioni e calcoli basati su uno stato già difettoso.

In un costrutto if/ else, viene eseguito solo uno dei blocchi, quindi nessuno dei due può essere considerato un passo "precedente" o "successivo". Il modo in cui ordinarli è quindi una questione di leggibilità e "fallire presto" non entra nella decisione.

Se la tua elsedichiarazione contiene solo un codice di errore, molto probabilmente non dovrebbe essere lì.

Invece di fare questo:

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

Fai questo

if not file.exists() :
  throw toysOutOfPram

if not validate(file) :
  throw foodAtMummy

# do stuff with file...

Non vuoi annidare profondamente il tuo codice semplicemente per includere il controllo degli errori.

E, come hanno già affermato tutti gli altri, i due consigli non sono contraddittori. Uno riguarda l'ordine di esecuzione , l'altro riguarda l' ordine del codice .

Dovresti seguirli entrambi.

Il consiglio "Arresto anticipato" / errore iniziale indica che è necessario testare gli input per possibili errori il più presto possibile.
Ad esempio, se il tuo metodo accetta una dimensione o un conteggio che si suppone sia positivo (> 0), allora la consulenza anticipata non riuscita significa che si verifica questa condizione all'inizio del metodo anziché attendere che l'algoritmo produca assurdità risultati.

Il consiglio di mettere al primo posto il caso normale significa che se si verifica una condizione, il percorso più probabile dovrebbe venire prima. Questo aiuta nelle prestazioni (poiché la previsione del ramo del processore sarà più frequente) e nella leggibilità, perché non è necessario saltare blocchi di codice quando si cerca di capire cosa sta facendo la funzione nel caso normale.
Questo consiglio non si applica realmente quando si verifica una condizione preliminare e si salva immediatamente (usando assert o if (!precondition) throwcostrutti), perché non vi è alcun errore nella gestione da saltare durante la lettura del codice.

Penso che @JackAidley abbia già detto l'essenza , ma lasciami formularlo in questo modo:

senza eccezioni (ad es. C)

Nel flusso di codice regolare, hai:

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

Nel caso "errore in anticipo", il tuo codice legge improvvisamente:

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

Se noti questo modello - a returnin un else(o anche if) blocco, rielaboralo immediatamente in modo che il codice in questione non abbia un elseblocco:

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

Nel mondo reale…

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

Questo evita l'annidamento troppo profondo e soddisfa il caso "break out early" (aiuta a mantenere la mente - e il flusso del codice - pulito) e non viola il "mettere la cosa più probabile nella ifparte" perché semplicemente non c'è elseparte .

C e pulizia

Ispirato da una risposta a una domanda simile (che ha sbagliato), ecco come eseguire la pulizia con C. Qui puoi usare uno o due punti di uscita, eccone uno per due punti di uscita:

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);
}

Puoi comprimerli in un punto di uscita se c'è meno pulizia da fare:

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);
}

Questo uso di gotova benissimo, se puoi affrontarlo; il consiglio di smettere di usare gotoè rivolto a persone che non possono ancora decidere da sole se un uso è buono, accettabile, cattivo, codice spaghetti o qualcos'altro.

eccezioni

Quanto sopra parla di lingue senza eccezioni, che preferisco di gran lunga me stesso (posso usare la gestione degli errori espliciti molto meglio e con molta meno sorpresa). Per citare 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 ;)

Ma ecco un suggerimento su come farlo bene in una lingua con eccezioni e quando vuoi usarli bene:

errore restituito a fronte di eccezioni

È possibile sostituire la maggior parte dei primi returncon l'eccezione. Tuttavia , il normale flusso del programma, ovvero qualsiasi flusso di codice in cui il programma non ha riscontrato, beh, un'eccezione ... una condizione di errore o qualcosa del genere, non deve sollevare eccezioni.

Ciò significa che…

# 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?"

... va bene, ma ...

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

… non è. Fondamentalmente, un'eccezione non è un elemento di flusso di controllo . Questo rende anche Operations strano per te ("quei programmatori Java ™ ci dicono sempre che queste eccezioni sono normali") e può ostacolare il debug (es. Dire all'IDE di interrompere qualsiasi eccezione). Le eccezioni spesso richiedono che l'ambiente di runtime rilasci lo stack per produrre traceback, ecc. Probabilmente ci sono più ragioni per evitarlo.

Questo si riduce a: in un linguaggio che supporta le eccezioni, usa tutto ciò che corrisponde alla logica e allo stile esistenti e ti sembra naturale. Se scrivi qualcosa da zero, concorda presto. Se scrivi una libreria da zero, pensa ai tuoi consumatori. (Non usare mai, abort()neanche in una biblioteca ...) Ma qualunque cosa tu faccia, non fai, come regola generale, un'eccezione se l'operazione continua (più o meno) normalmente dopo di essa.

consiglio generale eccezioni

Cerca di ottenere prima tutto l'utilizzo in programma delle eccezioni concordate da tutto il team di sviluppo. Fondamentalmente, pianificali. Non usarli in abbondanza. A volte, anche in C ++, Java ™, Python, un ritorno dell'errore è migliore. A volte non lo è; usali con il pensiero.

A mio avviso, "Condizioni di guardia" è uno dei modi migliori e più semplici per rendere leggibile il codice. Odio davvero quando vedo ifl'inizio del metodo e non vedo il elsecodice perché è fuori dallo schermo. Devo scorrere verso il basso solo per vedere throw new Exception.

Metti i controlli all'inizio in modo che la persona che legge il codice non debba saltare dappertutto il metodo per leggerlo ma invece scansiona sempre dall'alto verso il basso.

(La risposta di @mirabilos è eccellente, ma ecco come penso alla domanda per arrivare alla stessa conclusione :)

Sto pensando a me stesso (o a qualcun altro) a leggere il codice della mia funzione in seguito. Quando leggo la prima riga, non posso fare alcuna ipotesi sul mio input (tranne quelli che non verificherò comunque). Quindi il mio pensiero è "Ok, so che farò delle cose con i miei argomenti. Ma prima" puliamoli ", cioè uccidiamo i percorsi di controllo in cui non sono di mio gradimento." Ma allo stesso tempo , Non vedo il caso normale come qualcosa che è condizionato; voglio sottolineare che è normale.

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. */
}

Questo tipo di ordinamento delle condizioni dipende dalla criticità della sezione di codice in questione e dall'esistenza di valori predefiniti utilizzabili.

In altre parole:

A. sezione critica e nessuna impostazione predefinita => Fail Early

B. sezione non critica e valori predefiniti => Usa valori predefiniti nella parte altrimenti

C. tra i casi => decide per caso secondo necessità