Riga aggiuntiva nel blocco vs parametro aggiuntivo nel codice pulito

Contesto

In Clean Code , pagina 35, si dice

Ciò implica che i blocchi all'interno delle istruzioni if, else, while, e così via dovrebbero essere lunghi una riga. Probabilmente quella linea dovrebbe essere una chiamata di funzione. Questo non solo mantiene piccola la funzione che racchiude, ma aggiunge anche valore documentale perché la funzione chiamata all'interno del blocco può avere un nome ben descrittivo.

Sono completamente d'accordo, questo ha molto senso.

Più avanti, a pagina 40, parla degli argomenti delle funzioni

Il numero ideale di argomenti per una funzione è zero (niladic). Ne segue uno (monadico), seguito da vicino da due (diadico). Tre argomenti (triadici) dovrebbero essere evitati ove possibile. Più di tre (poliadici) richiedono una giustificazione molto speciale, e quindi non dovrebbero essere usati comunque. Gli argomenti sono difficili. Prendono molto potere concettuale.

Sono completamente d'accordo, questo ha molto senso.

Problema

Tuttavia, piuttosto spesso mi ritrovo a creare un elenco da un altro elenco e dovrò vivere con uno dei due mali.

O uso due righe nel blocco , una per creare la cosa, una per aggiungerla al risultato:

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            Flurp flurp = CreateFlurp(badaBoom);
            flurps.Add(flurp);
        }
        return flurps;
    }

Oppure aggiungo un argomento alla funzione per l'elenco in cui la cosa verrà aggiunta, rendendola "un argomento peggiore".

    public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            CreateFlurpInList(badaBoom, flurps);
        }
        return flurps;
    }

Domanda

Ci sono (dis) vantaggi che non vedo, che rendono uno di questi preferibile in generale? O ci sono tali vantaggi in determinate situazioni; in tal caso, cosa devo cercare quando prendo una decisione?

Queste linee guida sono una bussola, non una mappa. Ti indicano una direzione sensata . Ma non possono davvero dirti in termini assoluti quale soluzione è "migliore". Ad un certo punto, devi smettere di camminare nella direzione indicata dalla bussola, perché sei arrivato a destinazione.

Clean Code ti incoraggia a dividere il tuo codice in blocchi molto piccoli ed evidenti. Questa è generalmente una buona direzione. Ma se portato all'estremo (come suggerisce un'interpretazione letterale dei consigli citati), allora avrai suddiviso il tuo codice in pezzi inutilmente piccoli. Niente fa davvero nulla, tutto solo delegati. Questo è essenzialmente un altro tipo di offuscamento del codice.

Il tuo compito è bilanciare "più piccolo è meglio" con "troppo piccolo è inutile". Chiediti quale soluzione è più semplice. Per me, questa è chiaramente la prima soluzione in quanto ovviamente assembla un elenco. Questo è un linguaggio ben compreso. È possibile capire quel codice senza dover guardare ancora un'altra funzione.

Se è possibile fare di meglio, è notando che "trasformare tutti gli elementi da un elenco a un altro elenco" è un modello comune che può essere spesso estratto, usando un'operazione funzionale map(). In C #, penso che si chiami Select. Qualcosa come questo:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(BadaBoom => CreateFlurp(badaBoom)).ToList();
}

Il numero ideale di argomenti per una funzione è zero (niladic)

No! Il numero ideale di argomenti per una funzione è uno. Se è zero, allora stai garantendo che la funzione debba accedere alle informazioni esterne per poter eseguire un'azione. "Zio" Bob ha sbagliato molto.

Per quanto riguarda il tuo codice, il tuo primo esempio ha solo due righe nel blocco perché stai creando una variabile locale sulla prima riga. Rimuovi quel compito e stai rispettando queste linee guida per il codice pulito:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    List<Flurp> flurps = new List<Flurp>();
    foreach (BadaBoom badaBoom in badaBooms)
    {
        flurps.Add(CreateFlurp(badaBoom));
    }
    return flurps;
}

Ma questo è un codice molto lungo (C #). Fallo come:

IEnumerable<Flurp> CreateFlurps(IEnumerable<BadaBoom> badaBooms) =>
    from badaBoom in babaBooms select CreateFlurp(badaBoom);

Il consiglio "Clean Code" è completamente sbagliato.

Usa due o più righe nel tuo loop. Nascondere le stesse due linee in una funzione ha senso quando si tratta di alcuni calcoli casuali che richiedono una descrizione ma non fanno nulla quando le linee sono già descrittive. "Crea" e "Aggiungi"

Il secondo metodo in cui menzioni non ha davvero senso, poiché non sei obbligato ad aggiungere un secondo argomento per evitare le due righe.

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
    {
        List<Flurp> flurps = new List<Flurp>();
        foreach (BadaBoom badaBoom in badaBooms)
        {
            flurps.Add(badaBoom .CreateFlurp());
            //or
            badaBoom.AddToListAsFlurp(flurps);
            //or
            flurps.Add(new Flurp(badaBoom));
            //or
            //make flurps a member of the class
            //use linq.Select()
            //etc
        }
        return flurps;
    }

o

foreach(var flurp in ConvertToFlurps(badaBooms))...

Come notato da altri, il consiglio che la migliore funzione è una senza argomenti è distorto da OOP nella migliore delle ipotesi e chiaramente un cattivo consiglio nella peggiore

Il secondo è decisamente peggio, poiché CreateFlurpInListaccetta l'elenco e modifica tale elenco, rendendo la funzione non pura e più difficile da ragionare. Nulla nel nome del metodo suggerisce che il metodo si aggiunge solo all'elenco.

E offro la terza, migliore opzione:

public List<Flurp> CreateFlurps(List<BadaBoom> badaBooms)
{
    return badaBooms.Select(CreateFlurp).ToList();
}

E diavolo, puoi incorporare immediatamente quel metodo se c'è solo un posto dove viene usato, poiché il one-liner è chiaro da solo, quindi non ha bisogno di essere incapsulato dal metodo per dargli un significato.

La versione a un argomento è migliore, ma non principalmente a causa del numero di argomenti.

Il motivo più importante è che ha un accoppiamento inferiore , che lo rende più utile, più facile da ragionare, più facile da testare e con meno probabilità di trasformarsi in cloni copia + incollati.

Se mi fornisci con una CreateFlurp(BadaBoom), posso usare che con qualsiasi tipo di contenitore di raccolta: semplice Flurp[], List<Flurp>, LinkedList<Flurp>, Dictionary<Key, Flurp>, e così via. Ma con un CreateFlurpInList(BadaBoom, List<Flurp>), domani torno da te per chiedere in CreateFlurpInBindingList(BadaBoom, BindingList<Flurp>)modo che il mio modello di visualizzazione possa ricevere la notifica che l'elenco è cambiato. Che schifo!

Come ulteriore vantaggio, è più probabile che la firma più semplice si adatti alle API esistenti. Dici di avere un problema ricorrente

piuttosto spesso mi ritrovo a creare un elenco da un altro elenco

Si tratta solo di utilizzare gli strumenti disponibili. La versione più breve, più efficiente e migliore è:

var Flurps = badaBooms.ConvertAll(CreateFlurp);

Questo codice non solo consente di scrivere e testare, ma è anche più veloce, poiché List<T>.ConvertAll()è abbastanza intelligente da sapere che il risultato avrà lo stesso numero di elementi dell'input e preallocare l'elenco dei risultati nella dimensione corretta. Mentre il tuo codice (entrambe le versioni) ha richiesto di ampliare l'elenco.

Tieni a mente l'obiettivo generale: rendere il codice facile da leggere e mantenere.

Spesso, sarà possibile raggruppare più righe in un'unica funzione significativa. Fallo in questi casi. Occasionalmente, dovrai riconsiderare il tuo approccio generale.

Ad esempio, nel tuo caso, sostituendo l'intera implementazione con var

flups = badaBooms.Select(bb => new Flurp(bb));

potrebbe essere una possibilità. Oppure potresti fare qualcosa del genere

flups.Add(new Flurp(badaBoom))

A volte, la soluzione più pulita e più leggibile semplicemente non si adatta in una riga. Quindi avrai due righe. Non rendere il codice più difficile da capire, solo per soddisfare una regola arbitraria.

Il tuo secondo esempio è (secondo me) considerevolmente più difficile da capire rispetto al primo. Non è solo che hai un secondo parametro, è che il parametro viene modificato dalla funzione. Cerca ciò che Clean Code ha da dire al riguardo. (Non ho il libro a portata di mano in questo momento, ma sono abbastanza sicuro che sostanzialmente "non farlo se puoi evitarlo").