Comments on: Expressividade no Código

By: Marlon Patrick

Marlon Patrick — Sun, 21 Sep 2008 05:26:38 +0000

Muito bom cara..
super esclarecedor, de uma maneira simples e direta..
gostei muito..
principalmente por que to querendo me aprofundar nesse tema: Refactoring.
Lendo esse artigo me empolguei de vez..
parabéns.

By: pcalcado

pcalcado — Sat, 05 Jan 2008 02:10:25 +0000

Se você possui estes valores na tela provavelmente eles são parte do negócio, não? Se forem parte do negocio então deveriam estar no modelo de objetos, logo a mesma situação se aplica.

By: Marcilio

Marcilio — Fri, 04 Jan 2008 00:35:21 +0000

Mto bom.
Fui eu quem abriu a discussão no Guj. Foi um dia de revolta.
Pegando no exemplo da sua classe, imagine que temos uma tela de vendas super complexa, onde temos as variaveis:
xPre, xPreDolar, xPreco, xPrecoCalculado e por ai vai…
duro no ínicio p´saber o q cada uma representa…
A ideia de Refactoring é mto boa, mas inútil em alguns casos.

By: André Pinto

André Pinto — Wed, 02 Jan 2008 14:23:42 +0000

Em alguns casos acho melhor não ter documentação nenhuma do que ter uma documentação desatualizada há séculos… Acho que nomes de métodos, classes e atributos auto explicativos são essenciais para uma boa manutenção. E é claro: testar sempre!

By: Leandro

Leandro — Wed, 02 Jan 2008 12:24:31 +0000

Odeio códigos asquerosos! rsrsrs

Que o código fale por si…

By: elomarns

elomarns — Tue, 01 Jan 2008 08:56:19 +0000

Excelente artigo!

Eu sempre acreditei que documentação, incluindo comentários no código fonte, só deve ser criada se ela de fato agregar algum valor ao projeto.

Como você bem disse, uma vez criada a documentação, ela terá que ser atualizada em várias ocasiões, e a menos que ela tenha uma utilidade bem concreta, esta atualização será um enorme desperdício de tempo e recursos.

Talvez eu seja meio extremo nesse sentido, principalmente em relação aos comentários no código fonte, mas ao ler, por exemplo, o seu código, eu reforço a minha opinião, já que ele fala por si só, não só dispensando qualquer documentação, como também se tornando, de certa forma, uma espécie de documentação(mais ou menos como prega o BDD, se não me engano).

P.S.: Só pra evitar interpretações errôneas, eu não sou contra comentários, apenas sou contra comentários desnecessários. Um exemplo disso seria comentar simples getters/setters ou váriaveis com nomes significativos, como uma variável de instância chamada dataDeNascimento em uma eventual classe Cliente.

Além disso, também sou, na maioria dos casos, contra comentários que esclarecem aspectos da sintaxe do código, ao invés de focar na sua semântica, que é o que realmente importa.

By: Marcos Silva Pereira

Marcos Silva Pereira — Sun, 30 Dec 2007 02:18:25 +0000

E eis o meu ponto da discussão do GUJ: se o código já foi escrito de maneira clara o suficiente, para que raios gastar mais tempo escrevendo javadoc? Faz sentido? É util?

valeuz…

By: Clavius Tales

Clavius Tales — Fri, 28 Dec 2007 22:43:49 +0000

“Post” antológico! Parabéns!

By: Expressividade no código ou “Porque testes, código bem escrito e refactoring são melhores que qualquer documentação” — Learning on Rails

Fri, 28 Dec 2007 15:34:18 +0000

[…] o artigo do Phillip Calçado, “Expressividade no código“. Nele, Phillip fala o que todo programador já está cansado de saber mas que a maioria […]

By: Alberto

Alberto — Fri, 28 Dec 2007 12:49:41 +0000

Muito bacana o seu post Philip. Poucas pessoas no mercado tem conhecimento sobre o assunto - REFACTORING! Participei da discussão lá no GUJ e comentei sobre a utilização da refatoração. Para mim, refatorar é uma arte. Requer mto “cuidado”, ou seja, deixar o código funcional como antes, e para isso, os testes, como mencionado por você, estão ai para nos auxiliar (e ainda existem pessoas que sequer utilizam testes automatizados e falam q refatoram - Espero que o desenvolvedor tenha uma fé mto forte e mtos santos em sua mesa olhando para ele…rs )..
Abraços