Se você se sentiu obrigado a expandir um forro como
a = F(G1(H1(b1), H2(b2)), G2(c1));
Eu não te culpo. Isso não é apenas difícil de ler, é difícil de depurar.
Por quê?
- É denso
- Alguns depuradores só destacam a coisa toda de uma só vez
- É livre de nomes descritivos
Se você expandi-lo com resultados intermediários, você obtém
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);
e ainda é difícil de ler. Por quê? Ele resolve dois dos problemas e introduz um quarto:
-
É denso -
Alguns depuradores só destacam a coisa toda de uma só vez - É livre de nomes descritivos
- Está repleto de nomes não descritivos
Se você expandi-lo com nomes que adicionam um novo significado semântico, melhor ainda! Um bom nome me ajuda a entender.
var temperature = H1(b1);
var humidity = H2(b2);
var precipitation = G1(temperature, humidity);
var dewPoint = G2(c1);
var forecast = F(precipitation, dewPoint);
Agora pelo menos isso conta uma história. Ele corrige os problemas e é claramente melhor do que qualquer outra coisa oferecida aqui, mas requer que você indique os nomes.
Se você faz isso com nomes sem sentido como result_this e result_that porque você simplesmente não consegue pensar em bons nomes, então eu realmente prefiro que você nos poupe da desordem do nome sem sentido e expanda-o usando alguns espaços em branco bons e antigos:
int a =
F(
G1(
H1(b1),
H2(b2)
),
G2(c1)
)
;
É tão legível, se não mais, do que aquele com nomes de resultados sem sentido (não que esses nomes de função sejam tão bons assim).
-
É denso -
Alguns depuradores só destacam a coisa toda de uma só vez - É livre de nomes descritivos
-
Está repleto de nomes não descritivos
Quando você não consegue pensar em bons nomes, é tão bom quanto parece.
Por alguma razão, depuradores adoram novas linhas então você deve achar que a depuração não é difícil:
Seissonãoforsuficiente,imaginequeG2()foichamadoemmaisdeumlugare,emseguida,issoaconteceu:
Exception in thread "main" java.lang.NullPointerException
at composition.Example.G2(Example.java:34)
at composition.Example.main(Example.java:18)
Acho legal que, como cada chamada de G2() estaria em sua própria linha, esse estilo leva você diretamente para a chamada incorreta na principal.
Então, por favor, não use os problemas 1 e 2 como desculpa para nos deixar com o problema 4. Use bons nomes quando puder pensar neles. Evite nomes sem sentido quando você não puder.
Lightness Races no Orbit's indica corretamente que essas funções são artificiais e possuem nomes próprios inválidos. Então, aqui está um exemplo de aplicar esse estilo a algum código do mundo real:
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();
Eu odeio olhar para esse fluxo de ruído, mesmo quando a quebra de linha não é necessária. Veja como fica esse estilo:
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()
;
Como você pode ver, descobri que esse estilo funciona bem com o código funcional que está se movendo para o espaço orientado a objetos. Se você puder criar bons nomes para fazer isso em um estilo intermediário, mais poder terá para você. Até lá estou usando isso. Mas em qualquer caso, por favor, encontre alguma maneira de evitar nomes de resultados sem sentido. Eles fazem meus olhos doerem.