Si vous vous sentiez obligé d'étendre un one-liner comme
a = F(G1(H1(b1), H2(b2)), G2(c1));
Je ne t'en voudrais pas. Ce n'est pas seulement difficile à lire, c'est difficile à déboguer.
Pourquoi?
- C'est dense
- Certains débogueurs ne mettent en évidence que le tout en une fois
- Il est libre de noms descriptifs
Si vous développez avec des résultats intermédiaires, vous obtenez
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);
et c'est toujours difficile à lire. Pourquoi? Il résout deux des problèmes et en introduit un quatrième:
C'est dense
Certains débogueurs ne mettent en évidence que le tout en une fois
- Il est libre de noms descriptifs
- Il est encombré de noms non descriptifs
Si vous le développez avec des noms qui ajoutent une nouvelle, bonne signification sémantique, encore mieux! Un bon nom m'aide à comprendre.
var temperature = H1(b1);
var humidity = H2(b2);
var precipitation = G1(temperature, humidity);
var dewPoint = G2(c1);
var forecast = F(precipitation, dewPoint);
Maintenant au moins cela raconte une histoire. Cela corrige les problèmes et est clairement meilleur que tout ce qui est proposé ici, mais il vous oblige à donner les noms.
Si vous le faites avec des noms sans signification comme result_this
et result_that
parce que vous ne pouvez tout simplement pas penser à de bons noms, je préférerais vraiment que vous nous épargniez le fouillis de noms sans signification et que vous l'étendiez à l'aide de bons vieux espaces:
int a =
F(
G1(
H1(b1),
H2(b2)
),
G2(c1)
)
;
C’est aussi lisible, sinon plus, que celui qui porte des noms de résultats sans signification (même si ces noms de fonctions sont si géniaux).
C'est dense
Certains débogueurs ne mettent en évidence que le tout en une fois
- Il est libre de noms descriptifs
Il est encombré de noms non descriptifs
Quand vous ne pouvez pas penser à de bons noms, c'est ce qu'il y a de mieux.
Pour une raison quelconque, les débogueurs aiment les nouvelles lignes . Vous devriez donc constater que le débogage n’est pas difficile:
Si cela ne suffisait pas, imaginez que l’ G2()
on appelait à plus d’un endroit et que cela se produise:
Exception in thread "main" java.lang.NullPointerException
at composition.Example.G2(Example.java:34)
at composition.Example.main(Example.java:18)
Je pense que c’est bien que, puisque chaque G2()
appel est sur sa propre ligne, ce style vous conduit directement à l’appel incriminé.
Alors s'il vous plaît, n'utilisez pas les problèmes 1 et 2 comme excuse pour nous en tenir au problème 4. Utilisez les bons noms quand vous pouvez y penser. Évitez les noms dénués de sens quand vous ne pouvez pas.
Lightness Races dans le commentaire d'Orbit souligne à juste titre que ces fonctions sont artificielles et qu'elles portent des noms pauvres morts. Voici donc un exemple d'application de ce style à un code de la nature:
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();
Je déteste regarder ce flot de bruit, même lorsque l’ajout de mots n’est pas nécessaire. Voici à quoi ça ressemble dans ce style:
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()
;
Comme vous pouvez le constater, ce style fonctionne bien avec le code fonctionnel qui se déplace dans l'espace orienté objet. Si vous pouvez trouver de bons noms pour le faire dans un style intermédiaire, vous aurez plus de pouvoir. Jusque-là, je l'utilise. Mais dans tous les cas, s'il vous plaît, trouvez un moyen d'éviter les noms de résultats dénués de sens. Ils me font mal aux yeux.