Código limpo, um resumo pra quem tem pressa.
Esta é a parte 01, não sei dizer quantas partes irão ter, mas irei fazer um sumário aqui à medida que forem aparecendo novas 😉.
- Pt02:https://medium.com/@isaacmeira96/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-pt2-a282566e2891
- Pt03: https://medium.com/@isaacmeira/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-pt3-9b9d4a465bd0
Um ‘must read’ para todos os programadores, o livro trás consigo boas práticas de desenvolvimento, que todos nós, programadores, deveríamos saber e sempre tentar aplicar quando possível, neste artigo trago um pequeno resumo dos três primeiros capítulos do livro, que certamente serão de grande valia.
Estarei abordando somente o que é de linguagem geral, e vai servir tanto para programação funcional quanto para OO.
Introdução e definições de código limpo:
Em qual porta teu código está ?
O custo de ter um código confuso é a relação entre produtividade X tempo, qualquer manutenção se torna uma dor de cabeça tremenda, aumentando drasticamente o tempo para se achar o problema, além disso, nos seus capítulos iniciais o livro conta com a visão de vários programadores e autores referência no universo da programação, entre eles Bjarne Stroustrup, criador do c++.
Nomes Significativos
A questão de nomes de funções, variáveis, parâmetros, respostas, etc, provavalmente é uma das coisas que nós mais temos que nso atentar, sempre ao nomear algo devemos usar nome que indicam alguma coisa ao invés de um nome qualquer.
Além disso devemos evitar passar informações erradas, nomear métodos de forma errônea pode comprometer o entendimento do código, nesta questão, devemos ser bem diretos, nomeando aquilo que realmente faz.
Usar Nomes pronunciáveis:
Também, devemos nomear com nomes pronunciáveis, nunca nomeiar algo como por exemplo genTStp( ) para generateTimeStamp( ), vê que a segunda forma fica muito mais consiga, você já bate o olho e entende o que a função faz.
Evite o mapeamento mental:
Você DEVE escrever código que outros programadores possam ler de forma fácil, nenhum programador deveria pegar um código que não entende a lógica por trás de algo que seria simples se fosse simplemente escrito de outra maneira, de maneira geral os programadores são pessoas muito espertas, você pode escrever seu código da maneira que você entenda, porém, a diferença ente um programador esperto e um programador profissional é que este entende que clareza é fundamental, e escrevem código que outros possam entender.
Não dê uma de engraçadinho:
Ok, acho que ninguém em sã consciência faria isso em uma ambiente de trabalho, mas, o livro alerta para ‘piadinhas’ no código, se as pessoas que forem dar manutenção no seu código não tiverem o mesmo senso de humor que você, isso pode dar muito errado.
Conclusão:
Claro que isto é um mínimo da parte de nomeação do livro, também é importante frisar que Classes, Controllers, MiddleWares, Utils, e tudo o que é usado no desenvolvimento do sistema tem que ter nomes e métodos consisos, evitando contextos desnecessários e sem significado.
Funções
“ As funções são a primeira linha de qualquer programa…”
Pequenas:
A primeira regra para as funções é que elas devem ser pequenas !
O livro fala que as funções devem ter no máximo 20 linhas, claro, sabemos que em algumas situações não é algo possível que isso aconteça, mas a ídeia é que consigamos deixar elas o mais curtas possíveis, para melhor visualização, sabe quanto tu abre um código na sua IDE, você vê aquela função ao todo e o que ela faz, bate o olho e já sabe o que ela faz ao todo ? Isso é lindo !
Devem fazer apenas uma coisa:
Esse anda lado a lado com o princípio da responsabilidade única, esse princípio diz que cada classe deve ter uma única responsabilidade, no caso da função, ela tem que fazer apenas uma coisa, e tem que fazê-la bem.
O que seria uma coisa ? Dá-se pelo nível de abstração, seguindo o exemplo do livro:
Nessa função acima, algumas outras funções são chamadas, batendo o olho facilmente falaríamos que ela faz 3 coisas : Determina se a página é um teste | Se for, inclui SetUps e TearDowns | Exibe a página em HTML.
A função está fazendo uma ou três coisas ? Note que os três passos da função estão em um nível de abstração abaixo do nome da função, podemos descrever a função em umm pseudocódigo TO.
TO RenderPageWithSetupsAndTeardowns, verificamos se a página é de teste, se for incluímos setups e teardowns. Em ambos os casos exibimos a página em HTML.
Se a função faz apenas aqueles passos em um nível abaixo do nome da função, então ela está fazendo apenas uma coisa, e é isso o que buscamos.
Ler o código de cima para baixo: Regra decrescente
“ Queremos que o código seja lido de cima para baixo como uma narrativa”.
Em outras palavras, queremos poder ler o sistema como se fosse uma série de parágrafos TO , fazendo referência aos parágrafos TO consecutivos.
Nosso código então conta uma narrativa, onde cada função justifica a outra, podemos até imaginar o programa rodando em nossas mentes.
Parâmetros de funções:
“A quantidade ideal de parâmetros para uma função é ZERO. Depois vem um (Mônade), seguido de dois(Díade). Sempre que possível devem-se evitar 3 parâmetros(tríade). Para mais de 3 deve-se ter um motivo muito especial (políade) — mesmo assim não devem ser usados.”
O livro também diz que devemos evitar passar um parâmetro booleando para uma função por complicar a assinatura do método, além disso, quando se passar de 3 parâmetros, considerar passar um objeto/classe próprio para a execução daquela função.
Tratamento de erro é uma coisa só:
Aqui, deixo as palavras do próprio livro:
“ As funções devem fazer uma coisa só. Tratamento de erro é uma coisa só. Portanto, uma função que trata de erros não deve fazer mais nada. Isso implica que a palavra TRY que está dentro de uma função deve ser a primeira instrução e nada mais deve vir após os blocos de CATCH/FINALLY.
Conclusão:
Algumas outras coisas são citadas, como, as intruções de switch devem ser pequenas, devem-se usar nomes descritivos nas funções, tipos de formas, etc.
Também devemos evitar a repetição de código, esta que pode ser a raiz do mal de todo software, muitos princípios e práticas tem sido criados ao longo do tempo para evitarmos esse tipo de comportamento.
Em suma, como supracitado, as funções devem contar a história do sistema, estar em perfeita sincronia e formar uma linguagem clara e precisa para ajudar na narração.
Esses foram os 3 primeiros capítulos do livro, um resumo de algo de cerca de 50 páginas, sim, o livro é grande pra caramba !
Irei fazer sobre a maioria do livro, esta é a parte 01, na parte 02 veremos : Comentários, Formatação, Objetos e estruturas de dados, e tratamento de erros.
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.
