Refactoring in molti metodi - è considerato pulito o no? [duplicare]

Il LoC in un metodo è una misura completamente inutile. Le cose importanti sono la separazione delle preoccupazioni e la duplicazione del codice.

Un metodo dovrebbe fare solo una cosa, e quella cosa dovrebbe essere espressa nel suo nome. Altre cose dovrebbero essere lasciate ad altri metodi.

I problemi derivanti dalla duplicazione del codice non possono essere sovrastimati (in altre parole, sono sempre più grandi di quanto si pensi). E questo solo giustificherà anche i metodi con 1 riga di codice.

D'altra parte, un metodo che popola una grande forma con dettagli da un oggetto di grandi dimensioni può facilmente avere 50 o più linee di codice, ma senza una singola istruzione condizionale. Perché dovresti suddividerlo in pezzi più piccoli se non ci sono requisiti funzionali (o duplicazione del codice)?

I metodi più brevi sono molto più leggibili - meno cose da tenere a mente per comprenderli . I sostenitori più vocali del codice pulito probabilmente direbbero che quasi tutti i metodi dovrebbero essere più brevi di 8 righe. E praticamente tutti gli sviluppatori che sono interessati all'argomento concorderanno sul fatto che 70-80 linee di codice in un metodo sono troppe e dovrebbero essere suddivise.

Riguarda la separazione delle preoccupazioni. Il metodo dovrebbe rispondere a 1 domanda o prendere una decisione. E questo è tutto. Quindi, avere i metodi di 100 linee di codice significa che questi metodi fanno semplicemente troppo. I 7-8 metodi LoC sono assolutamente fantastici. L'altra domanda è - dove hai intenzione di mettere tutti questi metodi. Avere 20 metodi brevi in una singola classe è probabilmente un argomento di preoccupazione. Avere 30 di loro è, credo, la buona ragione per capire che c'è qualcosa di sbagliato nelle astrazioni. Mantieni tutto il più breve e semplice possibile.

C'è una scuola di pensiero che dice che 7-8 LOC è un po ' lungo per un metodo. Non mi associo a questo, ma direi che vado avanti, niente meno di uno schermo mi fa bene.

I metodi dovrebbero essere semplici come necessari , ma non più semplici.

LoC non è semplicemente una metrica valida. Invece, guarda a quanto fa un metodo. Un metodo dovrebbe generalmente fare una cosa. IMHO, a volte è ok per virare su 1 o 2 operazioni molto semplici. Ad esempio, calcolando il perimetro di un rettangolo:

Potrebbe essere:

public int GetPerimeter(int side1, int side2)
{
    totalWidthLength = side1 * 2;
    totalHeightLength = side2 * 2;
    return totalWidthLength + totalHeightLength;
}

-OR -

public int GetPerimeter(int side1, int side2)
{
    return DoubleSide(side1) + DoubleSide(side2);
}

private int DoubleSide(int side)
{
    return side * 2;
}

Personalmente, preferisco il primo metodo, anche se tecnicamente esegue più di una operazione. Allo stesso tempo, puoi anche avere metodi con molte linee di codice che sono semplici da leggere e comprendere.

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;
    customer.AddrLine1= textboxName.Text;
    customer.AddrLine2 = textboxName.Text;
    customer.OfficialName = textboxName.Text;
    customer.Age = textboxName.Text;
    customer.BirthDay = textboxName.Text;
    customer.NickName = textboxName.Text;
    customer.LastLocation = textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer.... = textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;
    customer....= textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

L'esempio sopra riportato è di circa 50 righe, ma potrebbe anche essere di 200 righe e non farebbe alcuna differenza. Ogni assegnazione di proprietà sull'oggetto cliente non aggiunge praticamente alcuna complessità, quindi il metodo a 50 righe rimane allo stesso livello di complessità del metodo medio a 4 righe. In effetti, direi che ha praticamente la stessa leggibilità del metodo seguente:

public void UpdateCustomer()
{
    customer Customer = new Customer();

    customer.Name = textboxName.Text;

    db.InsertOnCommit(customer)
    db.SubmitChanges();
}

Il metodo a 50 linee potrebbe probabilmente essere raggiunto in meno di 10 righe tramite l'uso di reflection e regex, iterando su ciascuna delle proprietà in Customer e cercando una casella di testo che abbia un valore LIKE corrispondente nel suo nome. Ovviamente, questo sarebbe un esempio di codice che è troppo intelligente e ricorre a stravaganti hack per raggiungere un ideale estetico. La linea di fondo è che LoC è una metrica di complessità / leggibilità estremamente inaffidabile. Tutti lo sanno già (il mio esempio CRUD non è in alcun modo insolito), eppure la maggior parte delle persone parla di quanto orribile LoC sia alla misurazione produttività, sentiamo costantemente su questo LoC per le regole del metodo che dovrebbero misurare la qualità del codice. In realtà non può essere in entrambi i modi.