5 Dicas Práticas de Clean Code Que Todo Desenvolvedor Deveria Adotar
Clean Code, ou código limpo, é uma filosofia de desenvolvimento cuja premissa é aplicar técnicas para aprimoramento da leitura e escrita de código. Escrevemos código para nós mesmos e outras pessoas, e não para a máquina. Profundo, não? Nem tanto, mas totalmente verdade. O true para o computador é o mesmo que !false (sem comparar custos de desempenho, otimização de código, etc), mas para um desenvolvedor o true é muito mais natural, claro e sensato. Legibilidade importa.
De uma forma bem resumida um código limpo é um código fácil de ler, manter e testar (também conhecido como excelência). Se quiser conhecer melhor a concepção e história por trás do termo pode dar uma olhada aqui.
Há várias situações em que podemos aplicar princípios de código limpo para garantir qualidade do código, alguns casos comuns estão descritos abaixo. O JavaScript (ES6) foi escolhido para exemplificar os cenários (o que não restringe a aplicação das situações em outras linguagens).
1. Use nomes significativos
Um nome descritivo e longo é melhor do que um nome curto e sem relevância. Prefira nomes que possuam significado a nomes sem contexto.
Isso vale para variáveis, funções, parâmetros, nome de arquivos. No caso de constantes defina nomes pesquisáveis, que possam ser facilmente encontrados!
2. Não adicione contextos desnecessários
Se o nome de sua classe/objeto já possui um contexto, não há necessidade de repetí-lo nos nomes das propriedades.
3. Use argumentos padrões
Prefira o uso de argumentos padrões ao invés de criar condicionais. Aplicar valores padrões para os argumentos irá substituir os argumentos undefined.
4. Não comente o óbvio
Bons códigos são auto explicativos e documentam-se, a maior parte, por si só. Vale a pena deixar um comentário para clarificar regras complexas, avisar sobre efeitos colaterais ou explicar determinado trecho em que seu código não foi tão inteligível.
Não deixe códigos inutilizados, comentados ou registros de alterações, o controle de versão existe por uma razão e deve ser utilizado nesses casos!
5. Defina um padrão e faça uso
Cada desenvolvedor possui preferências de formatação, o que a torna o processo de padronização bastante subjetivo, sem contar que algumas linguagens permitem maior grau de customização, aceitando diferentes tipos de indentação (tabs ou espaços), uso de aspas simples ou duplas, ponto e virgula opcionais ao final de cada sentença, etc. O imprescindível é a definição de um padrão único e sua utilização ao longo do projeto.
Você pode automatizar o processo de padronização aplicando regras de estilo no seu código e ainda gerar confiabilidade e eficiência com a utilização de linters.
Dica extra: Definições e chamadas de funções devem estar próximas
Em um cenário ideal, a definição deve estar logo acima da chamada função. Caso não seja possível, opte por alocar as definições das funções verticalmente próximas a suas chamadas.
A tendência natural é lermos códigos de cima para baixo, garantindo que definições e chamadas estejam próximas conseguimos ter uma percepção mais adequada da execução das instruções.
Como podemos observar, há diversos benefícios na utilização do Clean Code, mas não devemos tratá-lo como verdade absoluta. Os princípios podem (e devem) ser aplicados de forma gradual e seletiva em conformidade com a maturidade dos desenvolvedores. Além do mais, o time deve se sentir estimulado a participar de um processo de construção de código mais consistente e não fadado a aplicar refatorações.
Existem outros princípios e diretrizes que são aplicados nessa filosofia que são passíveis de discussão e que poderiam facilmente ter artigos exclusivos para cada um deles, como:
- Aplicação de código limpo na criação de testes (TDD);
- Escrita de códigos simples com o princípio KISS (Keep It Simple Stupid);
- Duplicação de código ao invés da criação de abstrações ruins com o princípio WET (Write Everything Twice);
- Evitar duplicação de código e garantir manutenibilidade com o princípio de DRY (Don’t Repeat Youself);
- Avaliação dos princípios WET e DRY aplicando AHA (Avoid Hasty Abstractions);
- Escrita de classes e API’s mais consistentes com o princípio de SOLID.
Conhece algum outro princípio que você acha válido que não está descrito? Sinta-se livre para contribuir!
Aqui na ArcTouch, temos várias oportunidades para você se atualizar e desenvolver projetos utilizando código limpo. Inscreva-se no nosso banco de talentos!
