Quando non utilizzare il ritorno anticipato? [duplicare]

Question

Quando non utilizzare il ritorno anticipato? [duplicare]

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

-1

L'annidamento è inevitabile, tuttavia nella maggior parte dei casi il ritorno anticipato è un'opzione più praticabile.
Considera il seguente frammento:

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
    } else if (1 == argument) {
         SubRoutineForSomething(argument);
    } else {
         SubRoutineForMe(argument);
    }

    return this;
}

Mi trovo costantemente a refactoring per

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);

         return this;
    }

    if (1 == argument) {
         SubRoutineForSomething(argument);

         return 1;
    }

    SubRoutineForMe(argument);

    return this;
}

L'unica eccezione è mantenere le cose asciutte, quindi invece di

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
         AnotherAction();

         return this;
    }

    if (1 == argument) {
         SubRoutineForSomething(argument);
         AnotherAction();

         return 1;
    }

    SubRoutineForMe(argument);
    AnotherAction();

    return this;
}

Preferirei usare

MyRoutine(argument)
{
    if (0 == argument) {
         SubRoutine(argument);
    } else if (1 == argument) {
         SubRoutineForSomething(argument);
    } else {
         SubRoutineForMe(argument);
    }

    AnotherAction();

    return this;
}

Ci sono grossi svantaggi per uscire presto? Sto passando dal lavoro lato server allo sviluppo del gioco (Javascript e linguaggio simile a C). Ci sono delle trappole che dovrei fare attenzione ai benefici che mi mancano (previsione dei rami)?

Spero che questo sia diverso da questa domanda .

conditions

posta Misiur 13.06.2015 - 23:26

fonte

3 risposte

Leggi altre domande sui tag conditions

Un simbolo - un significato? Quali sono i vantaggi delle classi proxy?

score 3 · Answer 1

Potrebbe essere un po 'supponente, ma consiglio di usare "early return" quando rende il codice più semplice da leggere, e specialmente quando riduce il livello di nidificazione. Tuttavia, IMHO la versione refactored del tuo primo esempio non soddisfa nessuna di queste due condizioni (in effetti, penso che nel tuo esempio la leggibilità sia un po 'diminuita), quindi che è esattamente un esempio in cui è non molto utile usare "early return".

score 1 · Answer 2

Il tuo refactoring non ha molto senso. Non vedo alcun scenario in cui restituiresti due tipi diversi, ovvero this o un numero intero, quindi return this quasi sicuramente andrà in fondo all'albero if e il codice originale è meglio.

Inoltre, if (0 == argument) non è più utilizzato, a meno che tu non stia utilizzando un compilatore C che non è abbastanza intelligente da avvisarti quando stai tentando di eseguire un'assegnazione non desiderata in una condizione if .

A seconda di ciò che stai effettivamente cercando di ottenere, potresti stare meglio con qualcosa di simile:

MyType MyRoutine(argument)
{
    switch(argument)
    {
        case 0: return someFunctionReturningAnInstanceOfMyType();
        case 1: return someOtherFunctionReturningAnInstanceOfMyType();
    }
    return default(myType);
}

che è pulito, semplice e sempre torna presto, tranne nel caso predefinito.

score 1 · Answer 3

Attendere di tornare fino alla fine della funzione è molto utile nelle lingue in cui è necessario rilasciare le risorse prima di tornare, perché poiché si ha solo un punto di uscita, si può essere certi che si sta ripulendo prima di partire.

Nelle lingue che dispongono della garbage collection automatica, tornare presto non ha questo svantaggio. Infatti, Rubocop, un analizzatore di codice statico per Ruby, incoraggia i metodi di refactoring a tornare presto quando si controllano i parametri. Questa è chiamata clausola di salvaguardia . Nella mia esperienza personale, aiuta davvero a chiarire le cattive se / else catene in determinate situazioni.

Dici che potresti programmare sia in linguaggio di tipo C che in JavaScript. Ritorno per sempre in JavaScript per questi motivi. Tuttavia, sarebbe meglio evitarlo nei linguaggi di tipo C, altrimenti dovresti duplicare (o dimenticare) il codice di pulizia.