Se ti sei sentito in dovere di espandere un solo rivestimento come
a = F(G1(H1(b1), H2(b2)), G2(c1));
Non ti biasimo. Non è solo difficile da leggere, è difficile eseguire il debug.
Perché?
- È denso
- Alcuni debugger evidenzieranno il tutto solo in una volta
- È privo di nomi descrittivi
Se lo espandi con risultati intermedi ottieni
var result_h1 = H1(b1);
var result_h2 = H2(b2);
var result_g1 = G1(result_h1, result_h2);
var result_g2 = G2(c1);
var a = F(result_g1, result_g2);
ed è ancora difficile da leggere. Perché? Risolve due dei problemi e ne introduce un quarto:
-
È denso
-
Alcuni debugger evidenzieranno l'intera operazione in una sola volta
- È privo di nomi descrittivi
- È ingombra di nomi non descrittivi
Se lo espandi con nomi che aggiungono un significato nuovo, buono, semantico, ancora meglio! Un buon nome mi aiuta a capire.
var temperature = H1(b1);
var humidity = H2(b2);
var precipitation = G1(temperature, humidity);
var dewPoint = G2(c1);
var forecast = F(precipitation, dewPoint);
Ora almeno questo racconta una storia. Risolve i problemi ed è chiaramente migliore di qualsiasi altra offerta qui, ma richiede di trovare i nomi.
Se lo fai con nomi privi di significato come result_this e result_that perché semplicemente non riesci a pensare a nomi validi, preferirei che tu ci risparmi la confusione di significato senza nome e la espandi usando alcuni buoni spazi bianchi:
int a =
F(
G1(
H1(b1),
H2(b2)
),
G2(c1)
)
;
È altrettanto leggibile, se non di più, di quello con i nomi dei risultati privi di significato (non che questi nomi di funzioni siano così eccezionali).
-
È denso
-
Alcuni debugger evidenzieranno l'intera operazione in una sola volta
- È privo di nomi descrittivi
-
È ingombra di nomi non descrittivi
Quando non riesci a pensare a nomi di qualità, è buono come lo è.
Per qualche motivo i debugger amano le nuove linee quindi dovresti trovare che il debugging non sia difficile:
Seciònonbastasse,immaginaG2()èstatochiamatoinpiùdiunpostoepoièsuccesso:
Exception in thread "main" java.lang.NullPointerException
at composition.Example.G2(Example.java:34)
at composition.Example.main(Example.java:18)
Penso che sia bello il fatto che ogni G2() chiamata sia sulla propria linea, questo stile ti porta direttamente alla chiamata all'origine della chiamata principale.
Quindi, per favore, non usare i problemi 1 e 2 come una scusa per attaccarci al problema 4. Usa dei buoni nomi quando riesci a pensarli. Evita nomi privi di significato quando non puoi.
Gare di leggerezza in Orbit commenta giustamente sottolinea che queste funzioni sono artificiali e hanno dei nomi scadenti. Ecco un esempio di come applicare questo stile ad un codice dal selvaggio:
var user = db.t_ST_User.Where(_user => string.Compare(domain,
_user.domainName.Trim(), StringComparison.OrdinalIgnoreCase) == 0)
.Where(_user => string.Compare(samAccountName, _user.samAccountName.Trim(),
StringComparison.OrdinalIgnoreCase) == 0).Where(_user => _user.deleted == false)
.FirstOrDefault();
Odio guardare quel flusso di rumore, anche quando non è necessario il word wrapping. Ecco come appare sotto questo stile:
var user = db
.t_ST_User
.Where(
_user => string.Compare(
domain,
_user.domainName.Trim(),
StringComparison.OrdinalIgnoreCase
) == 0
)
.Where(
_user => string.Compare(
samAccountName,
_user.samAccountName.Trim(),
StringComparison.OrdinalIgnoreCase
) == 0
)
.Where(_user => _user.deleted == false)
.FirstOrDefault()
;
Come puoi vedere, ho trovato che questo stile funziona bene con il codice funzionale che si sta spostando nello spazio orientato agli oggetti. Se riesci a trovare un buon nome per farlo in stile intermedio, allora più potere a te. Fino ad allora lo sto usando. Ma in ogni caso, per favore, trova un modo per evitare nomi di risultati privi di significato. Mi fanno male agli occhi.