Quale di questi stili di programmazione è migliore?
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
o
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
Quale di questi stili di programmazione è migliore?
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
o
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
In parole semplici:
L'importante non è il numero di righe ma la leggibilità del codice.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler)
Negli esempi che hai fornito, il secondo è definitivamente più facile da leggere.
Il codice sorgente è destinato alle persone da leggere.
Inoltre, i valori intermedi semplificano il debug del codice.
Le code one-line, d'altra parte, sono utili per mostrare ad altre persone che sei "intelligente" e che non ti interessa.
Dipende, e il tuo esempio non è utile per prendere una decisione.
Mentre meno linee di codice non sono sempre migliori (a un certo punto porta a offuscamenti), sono di solito , semplicemente perché ci sono meno cose da tenere traccia di quando cercando di capire il codice.
Nel tuo esempio specifico:
Se i nomi dei valori intermedi trasmettono effettivamente un significato che non è reso evidente dai nomi dei metodi e dei parametri usati per calcolare quei valori intermedi, allora aiutano a capire il codice.
Tuttavia, se i nomi dei valori intermedi non aggiungono informazioni, rendono il codice più difficile da capire, poiché sono uno stato aggiuntivo da tenere sotto controllo. Anche se sono immutabili, ti costringono a considerare se vengono utilizzati solo una volta o in luoghi diversi.
Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say '(x++ && false) || y += 2' instead of 'x++; y += 2' and the first variant is just so much more concise and clearer as you can tell because it contains no semi-colons honestly I almost threw up writing the second one I mean who wants to use a character whose name contains a word related to your butt that's just dumb and anyways semi-colons introduce lots of vulnerabilities like what if you typed 'while(true) ;' that would just keep running forever and so its clearly better to have no semi-colons to avoid problems like that overall I'd say programmer salaries should be inversely proportional to the number of newlines and semi-colons in their code because everyone knows as soon as you start using a metric like that it starts working even better than before you incentivized it
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)
Naturalmente, meno righe non sono sempre migliori. Ma nella mia esperienza, un numero inferiore di righe è spesso migliore di più linee in termini di leggibilità e manutenibilità. Ci sono eccezioni, naturalmente, e il tuo esempio potrebbe essere una tale eccezione.
Il peso è necessario per costruire un aereo. Ma dovrebbe essere nei posti giusti.
Nella prima versione, è difficile vedere quali parametri sono passati a quale metodo. Quindi la seconda versione è chiaramente migliore. In altri casi, tuttavia, potrebbe non essere così ovvio.
La principale differenza della seconda versione è che ti consente di assegnare un nome ai valori intermedi . Potrebbero esserci casi in cui questo nome è cruciale per la comprensione del codice.
Se tuttavia i valori intermedi sono comunque chiamati qualcosa come varOne , puoi anche semplicemente ometterli inserendoli all'interno.
Sembra che tu stia utilizzando JavaScript, il che modifica i parametri in modo leggermente lieve.
A meno che tu non abbia un motivo per archiviare quelli var , è meglio non inizializzarli affatto. Tuttavia, dovresti rendere la versione a singola istruzione più leggibile possibile, aggiungendo spazi bianchi e un commento.
//Do X, Y, Z....
var result = methodOne(
methodTwo(
a,
methodThree(b)
),
c,
d
);
Meno righe di codice sono sempre migliori?
Il corto è semplicemente no . Quello più lungo, no , perché dipende .
Quale di questi stili di programmazione è migliore?
Bene, il secondo è molto meglio in un aspetto. Se hai bisogno di eseguire il debug di ciò che accade, hai le variabili da ispezionare e più possibilità di collocare il punto di interruzione.
D'altra parte, non mi piace usare troppe variabili locali, perché devo inventare i nomi per loro. Odio nomi come risultato 1/2/3, perché dopo un po 'di tempo non so quale sia per cosa. Ma non voglio passare troppo tempo a inventare i nomi ... Il primo esempio è (per me) effettivamente più leggibile a causa di nomi di variabili errate nel secondo esempio.
Di solito inizio con il primo codice e lo converto in secondo prima quando devo eseguire il debug.
Tuttavia, se le espressioni sono più complesse, preferisco mantenere i risultati intermedi nelle variabili locali, ma quelle locali devono avere nomi che spiegano da soli . Solo allora il codice è più facile da leggere.
La mia regola empirica è di mettere ogni operazione sulla propria linea. Ciò è particolarmente utile quando si passa attraverso il codice con il debugger. Mi piace anche assegnare il risultato di un'operazione a una variabile prima di passarla in modo che possa rompere ed esaminare il suo contenuto. quindi invece di
var result = methodOne(methodTwo(a, methodThree(b)), c, d);
Vorrei andare
var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
Se non mi sbaglio, i compilatori JIT e JIT JITE compilerebbero i due esempi nello stesso modo.
in alternativa, vorrei scrivere un commento molto dettagliato prima della riga che spiega cosa sto facendo.
Sospetto che ciò che tutti vogliono sentire è "no".
Il fatto è che il tuo esempio non è abbastanza chiaro per dare una risposta solida.
resultThirdMethod è un nome orribile. trovo la prima versione molto più chiara della seconda.
Tuttavia, se potessi fornire i nomi delle tue variabili - i nomi che forniscono più informazioni rispetto alla semplice provenienza dei dati - allora potrebbe essere migliore. Tutto dipende dalla situazione attuale.
In questo particolare esempio non trovo la prima versione più difficile da leggere, è come leggere una semplice espressione aritmetica come (a + f(b)) * c * d . La seconda versione non aggiunge alcuna informazione che aiuti a comprenderla (a meno che le variabili non abbiano nomi significativi che aiutano a comprendere un processo complicato).
Ciò che ritengo un po 'problematico con la seconda versione è che introduce un'ulteriore complessità durante l'analisi del codice. Un programmatore che legge il codice deve pensare se resultThirdMethod o resultSecondMethod è usato da qualche altra parte, quindi solo per calcolare result . E se scrivi un metodo pieno di tali affermazioni non c'è una linea chiara di calcolo, devi controllare costantemente cosa viene calcolato da cosa e dove. Quindi, in questo caso, se vuoi la versione più dettagliata, ti suggerisco di incapsularla in una funzione separata:
function methodCombined(a, b, c, d)
var resultThirdMethod = methodThree(b);
var resultSecondMethod = methodTwo(a, resultThirdMethod);
return methodOne(resultSecondMethod, c, d);
}
// ...
result = methodCombined(a, b, c, d);
o almeno racchiuderlo in un blocco di codice in modo che l'ambito delle variabili sia immediatamente visibile:
var result;
{
var resultThirdMethod = methodThree(b);
var resultSecondMethod = methodTwo(a, resultThirdMethod);
result = methodOne(resultSecondMethod, c, d);
}
Dipende da quanto è familiare il lettore con questi operatori e il loro dominio problematico. Anche se tutti i metodi sono funzioni aritmetiche, può aiutare a scomporlo.
Rompere una formula più grande a piccoli passi può rovinare la leggibilità:
(let* ((term1 (* b b))
(term2 (* 4 a c))
(discriminant (- term1 term2))
(twoa (* 2 a))
(top1 (+ b (sqrt discriminant)))
(top2 (- b (sqrt discriminant)))
(root1 (/ top1 twoa))
(root2 (/ top2 twoa)))
(list root1 root2))
vs
(let* ((root1 (/ (+ b (sqrt (- (* b b) (* 4 a c))))
(* 2 a)))
(root2 (/ (- b (sqrt (- (* b b) (* 4 a c))))
(* 2 a)))
(list root1 root2))
Scomporre le formule in piccoli passi è ciò che fa un compilatore quando genera codice intermedio. (Fortran: FORmula TRANslator.)
Rompere le espressioni per la leggibilità aiuta, ma non "Fortran it" (esagerare).
Il miglior stile è quello che rende il codice più leggibile (per un umano, cioè, i computer non si preoccupano). Ma "leggibile" dipende molto su chi legge in modo che dipenda dal contesto. Questo è sufficiente, tuttavia, per rispondere alla tua domanda esatta: "È [qualunque cosa] sempre migliore"? Quindi no , dipende dal contesto.
La prima persona che deve leggere il codice è lo sviluppatore stesso. Se scrivi un codice tale che tu stesso sarai in grado di leggerlo e comprenderlo tra quattro settimane, avrai già fatto un buon lavoro - un lavoro molto migliore della maggior parte degli sviluppatori nel industria (ahimè).
Si possono aggiungere alcune generalità, comunque. Leggere il codice implica usare l'occhio e il cervello. Gli occhi umani si stancano più velocemente quando devono muoversi molto, soprattutto quando devono muoversi verticalmente (il movimento laterale è meno problematico). L'uso di un numero minore di righe di codice, a parità di altre condizioni, consentirà al lettore di afferrare il codice con un movimento oculare meno verticale, quindi è abbastanza buono.
D'altra parte, l'analisi della sintassi che va nel cervello vorrà usare quanti più "ancoraggi visivi" possibili, e soffrirà di certe attività, in particolare contando le parentesi. Diffondere il codice su più linee, con indentazione, aiuta il cervello. È davvero un compromesso tra affaticamento degli occhi e affaticamento cerebrale e, insisto, il giusto punto di equilibrio non è lo stesso per tutti.
In definitiva, è una questione di "buon gusto". Le persone che scrivono codice brutto sono anche le persone che sono felici di mangiare una pizza scadente.
Dai un cattivo esempio.
La soluzione che offri per risolvere meglio un problema ha un buon design, quindi può essere comprensibile e abbastanza utile da mantenere il codice breve.
Se riesci a creare codice più comprensibile aumentandolo, è qualcosa da fare, ma c'è un limite.
Penserò sempre che quel codice che ha sia un buon design che è abbreviato, garantisce più comprensibilità, più è breve.
Dovresti concentrarti su un buon design e quindi trovare i modi per rendere il codice abbastanza breve in modo che le persone che lo leggeranno possano capirlo senza farli scorrere e scorrere.
Quindi, per riassumere, non c'è una vera buona risposta a questo, l'importante è quanto bene dividi il tuo codice in funzioni e sezioni, e come puoi renderlo sia breve che facile da capire.
La citazione di Bill Gates è buona, ma c'è anche la citazione che parla di un pezzo di codice perfetto, che è quello in cui non puoi togliere nulla.
Questa è una di quelle questioni che penso tu abbia avuto modo di decidere in che modo funziona per ogni caso separato. Decidere se un particolare risultato dovrebbe essere memorizzato in una variabile intermedia è parte dell'essere un programmatore, parte del mestiere. Utilizzi le competenze acquisite insieme agli standard di codifica sul posto di lavoro.
Nei due esempi inventati qui sotto, probabilmente andrei con 1A e 2A, a causa della leggibilità (troppo rumore e ridondanza in 1B, uso troppo lungo e indiretto di un array anonimo in 2B). Ma non si può davvero inventare una lista esauriente di schemi in cui è possibile stabilire una via sull'altra - nuove situazioni sorgono continuamente man mano che l'arte della programmazione progredisce.
1A:
startManufacture(loadProductName(), isProductOk(loadProductState()));
vs.
1B:
String productName = loadProductName();
ProductState state = loadProductState();
boolean productIsOk = isProductOk(state);
startManufacture(productName, productIsOk);
2A:
boolean antennaCount = storage.getCount(currentDealer, items[ANTENNA_INDEX]);
boolean chassisCount = storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING);
orderManufacture(RADIO, antennaCount, chassisCount);
vs.
2B:
orderManufacture(RADIO, storage.getCount(currentDealer, items[ANTENNA_INDEX]), storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING));
Direi che entrambi gli esempi sono ugualmente cattivi , ma questo è solo a causa del codice di esempio insufficiente. Per essere in grado di dire se uno dei due è migliore, è necessario fornire un esempio reale.
Non c'è assolutamente alcuna correlazione tra il numero di linee del codice sorgente e la qualità del codice.
Supponendo che ignoriamo il fatto ovvio che il codice deve fare ciò che deve fare, l'aspetto più importante è che è facilmente comprensibile dai lettori.
Il modo "classico" per ottenere ciò è aggiungere commenti al codice che descrivano la funzionalità del codice. Nella mia esperienza personale, è ancora meglio usare identificatori descrittivi per metodi, variabili e costanti.
Se per esempio vedi una sequenza di codice sorgente come questa, capirai immediatamente che cosa dovrebbe fare, e puoi esaminare i singoli metodi e variabili (si spera) altrettanto facilmente determinano che fanno quello che dovrebbero fare:
if (a_new_game_is_starting && hand_not_dealt_yet()) {
deal_new_hand_to(all_players_at_table);
}
Nell'esempio sopra, non è necessario aggiungere alcun commento. Cosa direbbe un commento che non è facilmente comprensibile dal codice reale? Questo è qualcosa per cui ci sforziamo - a non è necessario aggiungere commenti al codice per descrivere cosa fa.
Questo non è qualcosa che è difficile da fare. Tutto ciò che richiede è che tu pensi a ciò che stai davvero cercando di realizzare, e dai il nome ai tuoi identificatori da un punto di vista funzionale.
Più importante della leggibilità è gestibilità , perché il motivo principale per cui leggiamo il codice è di mantenerlo. Mantenere spesso significa apportare modifiche al codice a causa di piccoli o grandi cambiamenti nei requisiti.
COSÌ, pensa a quali cambiamenti potrebbero esserci nei requisiti e cerca di renderli il più facili possibile. Se riesci a guidare il manutentore sul codice pertinente e permetti loro di apportare le modifiche con una modifica minima, penseranno che sei un grande programmatore!
OTOH, se le persone stanno leggendo il codice per verificarne la correttezza, assicurati che il tuo ragionamento sia chiaro sul motivo per cui è corretto. Se le persone dubitano della correttezza del tuo codice, è probabile che lo riscriveranno, il che probabilmente lo romperà. Per evitare ciò, assicurati che il codice si spieghi.
Inoltre, assicurati di spiegare le tue decisioni relative alle prestazioni, perché un buon metodo per distruggere il codice è riscrivere in un tentativo errato di renderlo più veloce.
return ($this->main->context != "ajax" || in_array($this->type, $this->definition->ajax)) ? eval('return method_exists($this,"Show'.ucfirst($this->type).'") ? $this->Show'.ucfirst($this->type).'('.(count($args) ? join(",",array_map(create_function('$a','return (is_numeric($a) || preg_match("/^array/",$a)) ? $a : "\"".$a."\"";'),$args)) : "").') : null;') : '';
Mi sono imbattuto in questo codice su un progetto che ho ereditato qualche tempo fa. Penso che dimostri bene il motivo per cui è una cattiva idea cercare di usare il minor numero possibile di linee. È completamente illeggibile e impossibile eseguire il debug.
L'ortografia può aiutare non solo con la leggibilità, ma anche con la scrittura.
Questa potrebbe sembrare una stupida domanda di intervista, ma una volta in un'intervista mi è stato chiesto di scrivere una funzione per ruotare un'immagine di 90 gradi. Vengono forniti l'origine e la destinazione (non è necessario eseguire alcuna allocazione di memoria) e la larghezza e l'altezza della sorgente. Sì, è un problema facile. Ti suggerisco di farlo prima di continuare e vedere se hai qualche problema.
.
L'hai fatto? L'hai provato? Poiché mi è stata posta la domanda in un'intervista, ho usato la domanda anche nelle interviste e quello che ho scoperto è che molti programmatori si confondevano. Scriveranno codice come questo
void Rotate90(const Pixel* src, Pixel* dst, int width, int height)
{
for (int y = 0; y < height; ++y)
{
for (int x = 0; x < width; ++x)
{
dst[???] = src[???];
Ed è lì che sarebbero rimasti bloccati. Passerebbero a volte fino a 20 minuti sulla lavagna cercando di capire cosa va in quelli ??? la zona. Molte volte penserebbero di avere la risposta e scrivere cose come
dst[x * width + (height - 1 - y)] = src[y * width + x];
ottenere il fatto che l'utilizzo di width con dst è sbagliato. O spesso otterrebbero x e y confusi in un lato o nell'altro.
Il problema è che x , y , width e height tutti i significati di swap perché ruotando di 90 gradi la destinazione diventa larga e larga come altezza che fa confusione con quelle variabili. Ho sempre desiderato che un programmatore aggiungesse alcune altre variabili per renderlo più chiaro, come questo
void Rotate90(const Pixel* src, Pixel* dst, int src_width, int src_height)
{
int dst_width = src_height;
int dst_height = src_width;
for (int src_y = 0; src_y < src_height; ++src_y)
{
for (int src_x = 0; src_y < src_width; ++src_x)
{
int dst_x = src_height - src_y - 1;
int dst_y = src_x;
dst[dst_y * dst_width + dst_x] = src[src_y * src_width + src_x];
}
}
}
Mi sembrava che rompere le cose nei loro significati espliciti avrebbe reso molto più facile scrivere il codice e molto più facile evitare errori. Mi sentivo come se vedessi un programmatore fare questo, penserei a loro come saggio e valutarli più in alto.
Sì, ci sono alcune ottimizzazioni che puoi fare. Non è questo il punto. Sì, la matematica all'interno dell'ultima affermazione potrebbe anche essere scomposta in linee separate. Anche quello andrebbe bene. Il punto è che l'aggiunta di più righe ha reso più facile la comprensione per la persona che scrive il codice, non solo una persona che lo legge più tardi. In questo caso perché il significato di x , y , width e height sono diversi in relazione a dst rispetto a src rendendo le variabili separate per ognuno rende il codice molto più chiaro da leggere E scrivere .
Proseguendo ... allo stesso modo è spesso utile poter esaminare i valori prima che una funzione venga chiamata, specialmente se si tratta di una funzione in una libreria o nel sistema in cui non si può intervenire. Se scrivi codice come questo
ctx.lineTo(x + Math.cos(angle) * radius, y + Math.sin(angle) * radius);
vs questo
var circleX = x + Math.cos(angle) * radius;
var circleY = y + Math.sin(angle) * radius;
ctx.lineTo(circleX, circleY);
Nel secondo stile ora puoi fermare il debugger sulla riga ctx.lineTo e ispezionare circleX e circleY . Potresti scoprire che sono NaN che probabilmente ti faranno controllare che x , angle e radius siano effettivamente i nomi corretti, cosa che non potresti fare nel debugger. (la modalità "strict" probabilmente lo rileva). Permette anche di registrare facilmente i valori
console.log("cx: " + circleX = ", cy: " + circleY);
Ancora un altro esempio,
class Person
{
public:
...
const String& name() const { return m_name; }
int age() const { return m_age; }
private:
string m_name;
int m_age;
};
vs
class Person
{
public:
...
const String& name() const
{
return m_name;
}
int age() const
{
return m_age;
}
private:
string m_name;
int m_age;
};
So che alcuni di voi urleranno a questo esempio perché il tuo stile personale vuole che i lanciatori e i setter siano 1 linea, ma ascoltami ... quando esegui il debug, a seconda del debugger, nel primo stile se metti un breakpoint su age o name il debugger non sarà in grado di ispezionare this né m_age né m_name in modo da non avere modo di controllare prima che la funzione restituisca cosa restituirà o quale oggetto si sta riferendo. Nel secondo stile puoi inserire i breakpoint sulle righe return e sarai in grado di ispezionare tutto.
Il punto di questa risposta è che più linee spesso non sono solo buone per la leggibilità. È spesso utile anche per la scrittura e il debug.
No.
In effetti, andrei oltre e direi che meno linee di codice sono raramente migliori.
Ora, questo non vuol dire non incapsulare le chiamate al metodo ecc. ma nell'esempio sopra, quando esegui il debug, sarà molto difficile vedere il risultato del metodo Tre e metodo Due quando è tutto in linea in quel modo.
Un sacco di codice in un metodo che fa molte cose è cattivo. Un sacco di piccoli metodi che vengono richiamati e assegnati a variabili locali migliorano la leggibilità, migliorano la manutenibilità e non hanno costi reali in quanto il compilatore ottimizzerà felicemente la distanza.
Pensa dalle basi.
Perché scriviamo il codice, quando vogliamo aggiungere alcune funzionalità e consegnarlo a un altro sviluppatore, può capire il tuo codice o no, perché è importante strutturare, perché dovresti seguire le linee guida standard di base?
Le risposte sono le seguenti:
Perché inseriamo commenti nel nostro codice.
Per gli sviluppatori (che possono sfruttare questa piccola documentazione per comprendere il codice e le funzionalità di routine), i computer oi sistemi di codifica / codifica ignorano i commenti e gestiscono solo il codice effettivo. Ad esempio: bundle di sviluppo e versione minifest,
Se usiamo la seconda opzione, è facile da leggere ed estendere e non sono necessarie molte indicazioni da un nuovo sviluppatore che estenda il nostro codice. Ma se usiamo la prima opzione che è meno documentata solo dalla persona che ha scritto questo codice o può capire il suo scopo, e non l'intera squadra. Stiamo lavorando a un ciclo di sviluppo rapido in cui dobbiamo lavorare su diversi progetti e non abbiamo molto tempo per coordinarci con gli altri reparti, quindi in questo caso il secondo approccio funziona bene e un altro sviluppatore può facilmente estendere le funzionalità. Tutto dipende dalla dipendenza: lavoriamo sulla modularizzazione del codice dove migliaia di sviluppatori lavorano su migliaia di funzioni e sanno solo cosa restituire, cosa passare alla funzione e quale variabile è assegnata a cosa, e per che cosa.
Per i singoli utenti o per i piccoli programmi, il primo approccio è ok quando il team sta lavorando insieme ma quando le persone lavorano da remoto cosa fare, questo è il punto che probabilmente andrà con la seconda opzione, l'ottimizzazione è un'altra tecnica per accorciare il codice ma solo dopo soddisfatto dell'output.
il computer è una macchina, capisce solo zero e il linguaggio di uno, ma se scriviamo codice che guida gli altri sviluppatori sul programma come secondo approccio, le nuove persone possono anche usarlo come guida o per modificare il programma,
il computer capisce 0 e 1 e l'umano può capire i commenti
quindi mi piace il secondo approccio che aiuta lo sviluppatore a capire cosa sta succedendo all'interno del loop o della funzione
ad esempio: ** supponiamo che tu stia lavorando su qualche progetto e tu usi la 1a via e in alcuni casi hai un'altra attività e un altro sviluppatore sta lavorando sul tuo codice, lo capisce o no? non è una domanda sulla semplicità o su come documentare, è tutto su ** come estendere il nostro codice al nostro partner quando vuole aggiornare il codice con il supporto gratuito di hassle.
Il secondo approccio di per i partner e gli sviluppatori e le prime opzioni funzionano bene quando lavoriamo sulla piattaforma web o scriviamo script in cui la dimensione del codice è importante
TL; DR:
Scrivi il tuo codice . Scrivi commenti quando lo stai scrivendo. Ti farà risparmiare tempo prezioso tre mesi dopo il tuo ritorno e non riesci a capire cosa sta facendo il codice. Inoltre, i tuoi collaboratori canteranno lodi su di te quando potranno effettivamente capire cosa stai facendo e sono facilmente in grado di estendere / refactare o modificare in altro modo il codice scritto da te.
Non esagerare , tuttavia.
Se meno righe di codice hanno senso, vai avanti e fallo in tante righe. Ma fai non fallo in modo che digitando poche righe ti venga chiesto di aggiungere commenti per spiegare il tuo codice. Dovrebbe essere il più autoesplicativo possibile.
Che dire
var result = methodOne( methodTwo( a,
methodThree(b)
),
c,
d
);
Questo sarà probabilmente ulteriormente migliorato con l'aiuto di un IDE decente, le linee di stampa che corrispondono alle parentesi graffe.
In poche parole, il cervello umano, per le persone più comuni , può contenere al massimo 7 cose diverse. Questo è per gente comune, e questa è una media. (Temo di non aver trovato la fonte della mia affermazione)
Di conseguenza, se vuoi scrivere codice che chiunque può leggere, non dovrebbe usare più di 7 variabili / concetti / funzioni / operazioni differenti.
ad esempio:
rotate(translate(rotate(translate(circle,50,0),0,10,pi),-50,0),0,10,pi)
lì è davvero difficile capire cosa sta succedendo, sorprendentemente questa linea non fa assolutamente nulla in senso geometrico:
circle = translate(circle,50,0)
circle = rotate(circle,0,10,pi)
circle = translate(circle,-50,0)
circle = rotate(circle,0,10,-pi)
questo è anche il motivo per cui è più facile leggere le funzioni che contengono meno di 40 righe di codice.
Entrambi gli esempi sono in realtà cattivi.
Cosa succede se methodOne fallisce? Cosa succede se methodTwo fallisce? Cosa succede se methodThree fallisce? Ovviamente qui hai omesso il controllo degli errori per chiarezza, ma è un punto importante: aggiungere un controllo degli errori aggiungerà più righe di codice (che su se stesso dovrebbe rispondere alla tua domanda) quindi linee extra di codice significativo che in realtà fa qualcosa non dovrebbe mai essere vista come una cosa negativa.
A parte questo, preferirei comunque il secondo esempio. Il motivo è perché è più mantenibile; puoi inserire più facilmente una chiamata a methodTwoPointFive tra le chiamate a methodTwo e methodThree, ad esempio, se i requisiti futuri lo richiedono.
Leggi altre domande sui tag code-quality coding-style clean-code