Código limpo, um resumo pra quem tem pressa. Pt2

Livros everywhere

Esta é a parte dois da série de artigos sobre o livro código limpo, neste artigo contemplaremos comentários, formatação, objetos e estruturas de dados, e tratamento de erros.

Para quem não viu a parte 01, segue o link (Futuramente será também um sumário).

• Pt01: https://medium.com/@isaacmeira96/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-b3a5c49b5fbc
• pt03 : https://medium.com/@isaacmeira/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-pt3-9b9d4a465bd0

No mais, vamos nessa.

Comentários

“ Nada pode ser tão útil quanto um comentário bem colocado. Nada consegue amontoar um módulo mais do que comentários dogmáticos e supérfluos… ”.

No livro o autor mostra-se um tanto agnóstico quanto aos comentários, seguindo o mesmo :

“ O uso adequado de comentários é compensar nosso fracasso em nos expressar no código. Observe que usei a palavra fracasso. E é isso que eu quis dizer. Comentários são sempre fracassos. Devemos usá-los porque nem sempre encontramos uma forma de nos expressar sem eles, mas seu uso não é motivo para comemoração ”.

No entanto, discordo do autor neste ponto, de se não usar comentários, concordo no ponto de não ter comentários inúteis mas não em não tê-los de forma alguma. Vou Resumindo e no final desta parte dou minhas considerações.

Comentários informativos

São um dos tipos mais bacanas de comentários, estes, transmitem informações como o retorno de algo.

Essa é uma função que retira a hora de um Date, o comentário mostra expressamente a saída do método, assim, quando qualquer outro programador pegar o código, vai enteder de fato o que é que está saindo daquilo ali.

Comentários TODO

As vezes é cabível deixar notas “To Do” ( Para fazer ),TODOS são tarefas que os programadores acham que devem ser efetuadas, mas, por alguma razão, não podem no momento.

No entanto, assim que fizer a implementação daquilo que estava no TODO, apague o comentário, não faz muito sentido ficar lá após isto.

Destaque

Pode-se usar um comentário para destacar a importância de algo que talvez pareça irrelevente.

Comentários redundantes

Às vezes, quanto o código em si já é bem explicativo, neste caso talvez não necessitamos comentar, pois os mesmos se tornam redundantes, exemplo, temos uma função de nome formatDateToHour() não é necessário um comentário para dizer o que ela faz, talvez apenas comentar como é a saída, como no exemplo supracitado.

Comentários enganadores

Nunca perca seu tempo para fazer um comentário desses, se for fazer um comentário, o faça direito, basicamente comentários enganadores são algo que expressam uma coisa ao contrário daquilo que se espera, por exemplo, um retorno que você comenta que sairia Date e ele sai como String, certifique-se que seus comentários são condizentes com aquilo que você deseja.

Comentários longos

Antigamente, antes dos sistemas de controle de versão, era necessário comentários extensos como changelogs, hoje em dia, já não é mais necessário, e esses tipos de comentários devem ser removidos.

Marcadores de posição

Algumas vezes, programadores gostam de fazer comentários de posição para se situar em meio ao código, algo como ‘ /////////… ’, este tipo de comentário é perfeitamente normal, mas lembre de excluí-los depois.

Códigos como comentários

O livro condena totalmente códigos como comentário, e eu concordo, você desenvolve um sistema e deixa alguns códigos comentados, um outro dev, pega, vê aqueles comentários e não apaga por achar que pode ser algo importante, se não é importante, apague-os.

Conclusão

Comentários são muito importantes, devendo ser usados mas com cuidado, comentários que só deixam ruídos no código, não fazem nada além de atrapahar outros desenvolvedores, além disso, se quer fazer um comentário, faça-o bem e perto do que ele descreve.

Formatação

Quanto à formatação do código, não há muito a se dizer nos dias de hoje, toda empresa praticamente, com sistemas mais recentes, tem sempre como padrão ter um código bem formatado, além disso, temos várias ferramentas ( Linters ) para ajudar-nos a fazer toda a formatação de forma automática, até algumas IDE´s já fazem isso por padrão.

O ideal é que sempre deixemos nosso código bem formatado, seguindo os padrões, além disso, é muito importante que sejam definidos esses padrões entre à equipe, por exemplo, em javascript, temos o ESLINT, nele, tem algumas opções diferentes de padrões de código, então, é necessário que os desenvolvedores escolham trabalhar num mesmo padrão.

Objetos e estrutura de dados

Essa parte do livro é bastante curtinha, pouco mais de 5 páginas, portanto resumi em uma listinha de frases importantes, segue.

• Declaramos variáveis como privadas para que ninguém dependa delas.
• Não queremos expor os detalhes de nossos dados. Queremos expressar nossos dados de forma abstrata.
• Um módulo não devem enxergar o interior dos objetos que ele manipula, Lei de Demeter.
• A forma perfeita de uma estrutura de dados é uma classe com variáveis públicas e nenhuma função.

Vou escrever a conclusão do mesmo modo que está no livro para maior compreenção.

Conclusão

“ Os objetos expõem as ações e ocultam os dados. Isso facilita a adição de novos tipos de objetos sem precisar modificar as ações existentes e dificulta a inclusão de novas atividades em objetos existentes. As estruturas de dados expõem os dados e não possuem ações significativas. Isso facilita a adição de novas ações às estruturas de dados existentes e dificulta a inclusão de novas estruturas de dados em funções existentes.

Em um dado sistema, às vezes, desejaremos flexibilidade para adicionar novos tipos de dados, e, portanto, optaremos por objetos. Em outras ocasiões, desejaremos querer flexibilidade para adicionar novas ações, e, portanto, optaremos por tipos de dados e procedimentos. Bons desenvolvedores de software entendem essas questões sem preconceito e selecionam a abordagem que melhor se aplica no momento. ”

Tratamento de erros

“ Pode parecer estranho ter uma seção sobre tratamento de erro num livro sobre código limpo, mas essa tarefa é uma das quais todos temos que fazer quando programamos…”.

Outro assunto muito importante é sobre o tratamento de erros, eles devem ser consisos para que não tenhamos problemas na saída, o livro passa várias dicas para que podemos evitar esses problemas.

Try-catch-finally

De certa forma, os blocos try são como as transações. Seu catch tem de deixar seu programa num estado consistente, não importa o que aconteça no try. Por essa razão, é uma boa prática começar com a estrutura quando você for escrever um código que pode disparar alguma exceção.

Por exemplo, você está fazendo uma chamada a uma api, mas pode ser que nem sempre esta Api lhe retorne o que você espera, ou retorne um erro, nesses casos é crucial estar dentro de um Try-Catch, para que ela faça algo se der tudo certo, ou dispare uma mensagem ou uma exceção com o que deu errado.

Forneça exceções com contexto

Cada exceção lançada deve fornecer contexto o suficiente para determinar a fonte da localização de um erro.

Crie mensagens de erro informativas e as passe junto com as exeções, mencionem a operação que falhou e o tipo de falha, vai garantir que não nos percamos nos códigos atrás de erros que deveriam estar expressos.

Não retorne nem passe NULL

Quanto retornamos null , basicamente estamos criando mais trabalho para nós mesmos e jogando os problemas encima dos chamadores. Basta esquecer uma verificação null para que o sistema fique fora de controle.

As vezes é melhor você fazer uma verificação exata ou uma Casa para verificar coisas que podem retornar null, a menos que você saiba expressamente que aquilo que você está checkando é realmente null e que ela não vai mudar até a checkagem.

“ Retornar null dos métodos é ruim, mas passar null para eles é pior. A mesnos que esteja trabalhando com uma API que espere receber null, você deve evitar passá-lo no código sempre que possível.

Em linguagens como Java ou outras fortemente tipadas, você provavelmente receberá um NullPointerException, para contornar isso o ideal é criar um novo tipo de exceção e lançá-lo, mas mesmo assim teríamos problemas em tempo de execução, então na maioria das vezes é melhor nem passar.

conclusão

Ter uma tratativa de erro robusta e com um bom coverage é essencial, e não é uma coisa que conflita um código limpo com tratativas de erros, podemos criar programas limpos e robustos se enxergarmos o tratamento de erro como uma preocupação à parte, algo que seja visível independente de nossa lógica principal.

Na medida em que somos capazes de compreender isso, podemos pensar um passo a grente de forma independente e dar um grande salto na capacidade de manutenção do nosso código.

Conclusão

Nessa etapa do resumo, foram apresentadas várias formas de melhorar o código, muitas se aplicam apenas em lilnguagens orientadas mas a maioria serve para todas as linguagens, especialmente a questão de comentários.

Agora, resumimos até o capítulo 07 do livro, um resumo de algo de cerca de 110 páginas, sim, o livro é grande pra caramba !

Irei fazer sobre a maioria do livro, esta é a parte 02, na parte 03 veremos : Testes de unidade, classes, e emergência.

Lembrando que estou resumindo coisas pertinentes a qualquer linguagem, no livro, existem tópicos que servem somente para Java, não entrarei em detalhes nestes.

Se gostou e quer que o trabalhe continue, dê 1 ou 50 claps (Sim, você pode dar 50 palminhas se isso ajudou em algo rsrsrs). Como sempre, espero que eu possa ajudar a comunidade de alguma forma, então se você tem dúvidas, sugestões ou comentários, deixe-me saber !

See ya.