Se ti sentissi in dovere di espandere una fodera come
a = F(G1(H1(b1), H2(b2)), G2(c1));
Non ti biasimerei. Non è solo difficile da leggere, è difficile eseguire il debug.
Perché?
- È denso
- Alcuni debugger metteranno in evidenza tutto in una volta
- È privo di nomi descrittivi
Se lo espandi con risultati intermedi, otterrai
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 introduce un quarto:
È densoAlcuni debugger metteranno in evidenza tutto in una volta- È privo di nomi descrittivi
- È ingombra di nomi non descrittivi
Se lo espandi con nomi che aggiungono un nuovo, buon significato 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 cosa offerta qui, ma richiede di trovare i nomi.
Se lo fai con nomi insignificanti come result_thise result_thatperché semplicemente non riesci a pensare a buoni nomi, preferirei davvero che ci risparmiassi il disordine di nomi insignificanti ed espanderlo usando qualche buon vecchio spazio bianco:
int a =
F(
G1(
H1(b1),
H2(b2)
),
G2(c1)
)
;
È altrettanto leggibile, se non di più, di quello con i nomi dei risultati insignificanti (non che questi nomi di funzioni siano fantastici).
È densoAlcuni debugger metteranno in evidenza tutto in una volta- È privo di nomi descrittivi
È ingombra di nomi non descrittivi
Quando non riesci a pensare a buoni nomi, va bene così.
Per qualche ragione i debugger adorano le nuove linee, quindi dovresti scoprire che il debug non è difficile:
Se ciò non bastasse, immagina di essere G2()stato chiamato in più di un posto e quindi è 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 che dato che ogni G2()chiamata sarebbe sulla propria linea, questo stile ti porta direttamente alla chiamata offensiva in linea di massima.
Quindi, per favore, non usare i problemi 1 e 2 come scusa per attaccarci al problema 4. Usa dei bei nomi quando riesci a pensarci. Evita i nomi insignificanti quando non puoi.
Lightness Races nel commento di Orbit sottolinea correttamente che queste funzioni sono artificiali e hanno nomi morti poveri. Quindi, ecco un esempio di applicazione di 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 lo scambio di parole. 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 scoperto che questo stile funziona bene con il codice funzionale che si sposta nello spazio orientato agli oggetti. Se riesci a trovare buoni nomi per farlo in stile intermedio, allora più potere per te. Fino ad allora lo sto usando. Ma in ogni caso, per favore, trova un modo per evitare nomi di risultati insignificanti. Mi fanno male agli occhi.