Clean Code - Criando código limpo!

von.juliano:

Inspirado por uma palestra do Agile Brazil 2011, escrevi um post com um resumo de pontos que considero “os primeiros passos para um código melhor” do livro Clean Code, do Uncle Bob: http://vonjuliano.wordpress.com/2011/07/07/codigo-limpo/

Não me entendam mal ao divulgar um link do meu blog dessa forma, mas eu realmente gostaria que as pessoas passasem a produzir código limpo e de qualidade, então vejo essa como uma pequena contribuição, tentando dispertar o interesse pelo livro.

Como foi muito falado durante o evento, código de verdade é código testado e limpo!

Flw! :thumbup:

Ótimo o seu posto no Blog, tudo que você falou, me fez pensar nos meus erros quando estou programando, ou seja, eu também produzo código ‘sujo’. Pena que meu inglês é péssimo, senão eu iria comprar este livro, para melhorar o meu jeito de programar.

Sim. É um apelo bastante válido.
Eu adicionaria a recomendação de saber reconhecer um mau cheiro no código. É o primeiro passo para corrigi-lo.
E também colocaria uma recomendação de bibliografia, como o próprio livro que você citou, o clássico livro de refatoração e, talvez, alguns livros falando sobre projeto de software.

Eu li este livro, e de fato, é de um conteúdo sem igual. Também há um outro livro chamado Refactoring: Improving the Design of Existing Code, do Martin Fowler que é sensacional. Este último, como o título sugere, trata da “refatoração”.

Já li a versão traduzida desse livro e realmente é muito bom. Coisas simples, como nome de métodos e variáveis fazem uma grande diferença na hora de dar manutenção em um código. O livro é bem prático e de fácil entendimento. Recomendo.

Aproveitando a deixa, se estiverem usando eclipse

Em Potential programming problems alterem o valor das propriedades Null pointer access e Potential null pointer access para Error

Você leu este livro baixado da internet ou você comprou o livro traduzido??? Se você comprou, onde você comprou???

Eu ganhei o livro. Mas ja vi em um monte de lugar para comprar. Faz uma busca no buscape.

André Fonseca:

Aproveitando a deixa, se estiverem usando eclipse

Em Potential programming problems alterem o valor das propriedades Null pointer access e Potential null pointer access para Error

André, qual a vantagem de se fazer esta modificação?

Grato
Ademir

AdemirPinto:

André, qual a vantagem de se fazer esta modificação?

Grato
Ademir

Um warning geralmente é sinal de que você está fazendo algo potencialmente perigoso. Se você não souber o que está fazendo (e ter certeza que funciona) é melhor mudar.

Acredito que a sugestão dele seja porque esses warning sempre representam problemas reais. Daí o código nem compila com essa falha.

Achei fantástico essa parte. A última vez que sugeri aqui que os desenvolvedores tinham que ter responsabilidade pelo que entregam, disseram que eu era gerente…

ViniGodoy e Andre Rosa
Obrigado pelas sugestões, como falei no post, esse é o primeiro passo, creio que a leitura do Clean Code deva ser a primeira de muitas. Quanto ao Refactoring do Martin Fowler, vejo como o segundo passo, já que este é uma referência de como refatorar, enquanto o Clean Code é mais conceitual.

mauricionarcizo
A idéia é incomodar mesmo, assim como me senti incomodado durante a palestra. Eu já tinha lido o livro, já aplicava suas práticas, mas ainda sim não fiquei satisfeito após o que ouvi. Além disso, trabalhei com muitas pessoas que nunca nem ouviram falar do livro, então decidi escrever para espalhar a idéia, e espero que faça com que as pessoas pensem no assunto e leiam o livro.

Sobre o inglês, eu tenho o Refactoring em português e a tradução é horrível. Aconselho a adquirir livros dessa linha em inglês mesmo.

AbelBueno
Não desista de fazer a diferença. Procure falar com as pessoas certas, e procure formas de mostrar que testes e código limpo trazem benefícios. Use ferramentas como o Sonar, que permitem mostrar com gráficos esses números, e melhor, um plugin que faz um cálculo aproximado do quanto a dívida técnica do projeto custa para a empresa em dinheiro. É algo que pode chamar a atenção.

AdemirPinto:

André, qual a vantagem de se fazer esta modificação?

Grato
Ademir

Você só vai conseguir capturar este erro quando rodar o seu programa, fazendo o que falei você irá ter um erro na hora de compilar estas classes.

Imagine que você criou um código assim

Só que você esqueceu de criar o aluno antes de chamar o método

Na hora de rodar a sua classe você irá receber o NullPointerException

Fazendo esta checagem anterior você irá poupar o trabalho de verificar estes erros depois que o seu código já estiver rodando no cliente, entendeu?

Tem muitas outras checagens que você pode fazer antes (checagem estática) e existem várias ferramentas que ajudam você a fazer isso (por exemplo o findbugs)