Executando verificação de segurança...
Em resposta a Clean Code no Cinema
2

Estava prestes a positivar a postagem quando vi o segundo exemplo.

Em parte tem o gosto. Eu acho a segunda forma bem menos legível que a primeira, principalmente porque eu, e quase todo mundo, estamos acostumados com a primeira.

Contexto é importante. E estar acostumado é um contexto importante. Em muitos casos, até fazer "menos certo" pode ser melhor pelo contexto.

Ainda bem que não mudou i por contador. Muita gente defende isso e diz exatamente o que está está escrito aí, é mais legível usar um nome de variável que diz o'que ela é. Mas a pessoa ignora que i diz melhor ainda, porque as pessoas estão acostumadas. E a pessoa diz que precisa fazer isso porque assim é "Clean Code". Ou seja, a pessoa leu o livro, não entendeu nada e fez errado. O livro pode ser uma faca de dois gumes, porque se a pessoa não souber aplicar, ela começa implementar o que aprendeu de forma equivocada. A pessoa usou o livro como receita de bolo, que eu sempre falo que não pode ser feito.

Por isso eu recomendo ler o livro porque ele ensina muita coisa, mas com criticidade, porque ele ensina errado algumas coisas, e porque a pessoa vai ignorar a parte do contexto ela aprenderá errado, mesmo que o livro ensinou certo.

E se i é mais adequado que contador, então por que tamanhoDoArray é mais adequado que arrayInteressante.length? Simples, não é.

As pessoas estão acostumadas com a forma direta sem variável, então é mais legível assim. As pessoas sabem que isso é o tamanho do array, e quem não souber não sabe programar ainda, tem que passar longe do Clean Code, não é hora pra isso. È como fazer isto (caso real em um lugar que eu trabalhei, e que pedi demissão porque quem mandava dizia que tinha que fazer assim porque estava no Clean Code, e eu não trabalho com gente estúpida):

    //este método inicializa os componentes
InicializaComponentes();
A justificativa era que o estagiário precisava entender. Isso está errado por várias razões, e lamento se não as percebe.

Mas tem mais problemas. Semanticamente os dois códigos são diferentes. Pode ser que não faça diferença, e é comum não fazer, até que faça. Até que alguém mude algo lá e faça. Pode ser que a segunda forma seja a mais correta, mas precisa analisar o contexto. Pode ser que não queira garantir que o tamanho seja fixo, pode ser que o tamanho mude dentro do laço, ou concorrentemente.

E tem a questão da performance. Dependendo da tecnologia usada (não necessariamente a linguagem) pode ser que o segundo caso seja menor performática, ou pelo menos seja igual. Especular sobre o que parece intuitivo nunca é bom sobre performance. Existem casos reais que não ocorrem de fato. Muitas linguagens otimizam isso e não precisam ter essa preocupação.

Também é questão de gosto e costume, mas escrever o for separando em linhas é bem esquisito, me parece menos legível, e talvez nem seja o caso de usar um for. Indentação dupla no mesmo bloco como se fossem dois blocos torna menos legível, pelo menos para quem está treinado de outra forma, mas provavelmente em qualquer caso.

Sem falar que provavelmente deveria usar um for ... of (se não for JS pode ser um for each ou algo parecido).

E minha discordância final é que ser legível e ter mais performance não andam juntos. Tem casos que até é verdade, mas frequentemente não ocorre, o legível deixa menos eficiente. O que pode não ser problema, mas ocorre. Existem muitas exceções, mas códigos maiores tendem ser mais lentos, sem entrar em casos específicos.

Claro que a base do texto está correta. O perigo mora nos detalhes. Porque assim evita ser uma psicopata com seu ídolo embaixo do braço. Se você fizer algo que as pessoas naõ estão acostumadas, você está pensando em você, não no outro.

Por isso que eu semrpe falo que é preciso aprender todos os fundamentos, os conceitos, as nomenclaturas e os padrões que todos conhecem. Imagine uma junta médica conversando com "dodói disso, dodói daquilo", as pessoas precisam falar a mesma língua que seja inequívoca entre profissionais.

Em engenharia temos que dominar todos os aspectos, caso contrário... (veja o vídeo).

Faz sentido para você?

Espero ter ajudado.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Carregando publicação patrocinada...
1

Extremante importante teus apontamentos, Maniero!

Muito obrigado pela contribuição, o que você comentou reafirma algo que concordo bastante, os detalhes.

As vezes sinto que pessoas comentam sobre Clean Code se referenciando algo que "eu fiz ou não fiz hoje", algo binario, quando na verdade é uma construção ao longo do tempo - com ou sem um time.

O contexto, na minha opinião, é a chave pra esse entendimento em conjunto. Como por exemplo o própio portugues brasileiro com seus sotaques e girias, onde certas expressões estão alocadas apenas naquela determinada região e aplicadas em outros lugares pode trazer bastante confusão.

Uma vez estipulado e entendido por todos, a saúde e qualidade do código ganham aumento expressivos, principalmente na economia de tempo e dinheiro.

1