I metodi dovrebbero sempre tornare da un posto? [duplicare]

Question

I metodi dovrebbero sempre tornare da un posto? [duplicare]

#1 da (2 voti)

4

Ho avuto una piccola discussione con un collega per sapere se un metodo dovrebbe essere scritto in questo modo:

public Thing getThing(int key){
    if(!things.containsKey(key))
        return null;

    return things.get(key);
}

o questo:

public Thing getThing(int key){
    Thing t = null;

    if(things.containsKey(key))
        t = things.get(key);

    return t;
}

Personalmente ritengo che la prima via sia più pulita e più facile da leggere. Tuttavia, mi è stato insegnato a scuola che dovresti sempre tornare da un posto. Dal momento che nessuno è mai stato in grado di darmi una buona ragione per preferire l'uno sull'altro (a parte le preoccupazioni stilistiche), di solito vado con ciò che rende il codice più facile da leggere.

Ci sono dei buoni motivi per preferire un modo rispetto all'altro o varia a seconda della situazione?

coding-style

posta ConditionRacer 02.02.2013 - 19:38

fonte

1 risposta

Leggi altre domande sui tag coding-style

Sto cercando di capire il modo migliore per capire come memorizzare nella cache gli oggetti del dominio Unit test markup building logic

score 2 · Answer 1

I metodi dovrebbero sempre tornare da un posto? NO.

Non dovrei mai usare goto? NO.

Non dovrei mai ereditare forme non polimoriche? NO.

Ci sono molte domande come queste, che si trovano come sedimenti nella storia dei linguaggi informatici, creando una sorta di culture settarie (per non chiamarle anche Religioni) dove tutto deve essere Puro, Intatto, Elegante, Vergine, .. .

Fortunatamente la maggior parte degli "umani" (in senso "umanistico") non seguono queste regole, altrimenti l'umanità era già stata estinta per l'impossibilità pratica per le persone di incontrarsi. (fuori metafora: il programma deve funzionare, non solo essere elegante!)

Tutte queste regole provengono da filosofie delle lingue con tutte le buone intenzioni di mantenere le cose in ordine, ma ciò può fallire drammaticamente quando tale ordine diventa una mania.

Personalmente evito di fidarmi di insegnanti o mentori che creano la loro leadership abusando di piccole parole come "sempre", "mai": qualunque sia la loro esperienza, non possono avere la conoscenza del tutto e ogni volta.

Evitare retunrs spurie può essere una buona cosa, ma farlo introducendo 4 variabili e 5 livelli di if-nesting è male più di un ritorno multiplo.

Andare casualmente su e giù saltando arbitrariamente in strutture di codice è male, ma introdurre una rete di stati di variabili false per evitare che goto-s descriva una macchina di stato è anche peggio (dal momento che ti rende più in grado di identificare gli stati, che può essere facilmente definito come etichette di salto)

C'è stato un tempo (prova a cercare un elenco di un programma BASIC degli anni '80) in cui le variabili non avevano un ambito, dove le etichette erano solo numeri, dove se solo si poteva fare un goto. Saltare al centro del ciclo saltando l'inizializzazione dell'indice, o modificare un indice di loop all'interno di una subroutine chiamata, o saltare nel mezzo di una funzione dall'esterno era la principale fonte di errori impossibile da trovare, all'interno del codice scritto per le macchine e non per i manutentori.

Ma oggi le variabili hanno scope, goto-s ha scope, la funzione call ha scope. Tutti questi "strumenti" hanno limiti di influenza molto ben definiti. Il problema non è di evitare questo o quello strumento, ma di usare quello giusto, nel posto giusto entro i limiti appropriati. Le funzionalità linguistiche esistono per una ragione! Non lasciarli cadere solo per purezza: lasciali quando non ti aiutano.

Quando si codifica qualcosa, anche una cosa alle possibili varianti: cosa dovrei modificare se la mia specifica. cambia questo o quello? Cosa (tra questo o quello ) sarà il "prossimo requisito" più probabile dai miei utenti / clienti / capi?

Una volta che hai fatto una previsione ragionevole, il codice in un modo che ti aspetti di cambiare, può essere facilmente trovato e può essere facilmente modificato senza troppe "cose al contorno" per dare un'occhiata a un cambiamento. 5 livelli di se, per evitare quattro ritorni è nella maggior parte dei casi non la strada da percorrere, poiché rischia di rendere tutto il testo da modificare se è richiesta un'altra condizione di fuga.