Baixe Estudo do Código Limpo (Clean Code) e outras Notas de estudo em PDF para Análise de Sistemas de Engenharia, somente na Docsity!
Clean Code
Estudo da escrita de Código Limpo
Citação “ Toda linha de código que você escreve deve estar testada, e Ponto final.” Uncle Bob/ Robert C. Martin autor de Code Clean book.
Seja Profissional Você é responsável pelo seu código, pela estrutura do código por isso seja profissional e escreva códigos que não exijam altos custos ou grande esforço para mantê-lo ou entendê-lo. Estude e procure conhecimento com profissionais, você é responsável pelo seu futuro, pelo seu conhecimento e seu estudo, não seu chefe, nem a empresa onde você trabalha. Seja profissional, você recebe para resolver os problemas da empresa e não os seus durante as 40 horas semanais de seu trabalho. Então vamos fazer uma continha simples e dar exemplos:
- Sua semana contém 168 horas
- Você trabalha 40 horas para seu empregador
- Reserve e preserve 20 horas para sua carreira
- Destes sobram 108 horas e você pode aproveitar para...
- 56 horas/8 horas diárias ou 48 horas/6 horas diárias para dormir
- 52 ou 60 horas para entretenimento/família/amigos, etc
Sentimentos ao ver código ruim Raiva – Ao tentar ler um código sujo, feio, fedido é comum sentir raiva de quem fez algo tão depreciável. Perda de Tempo – Perder algo tão precioso e extremamente útil tentando ler, entender, interpretar, desmistificar um código ruim. Frustração – Sentimento sentido, pois você se vê em um beco tão fundo quanto possível, mas sem uma única saída. Pois você tenta enxergar e corrigir o problema que aquele código causa, mas de tão ruim não sentimo-nos capazes de resolver o problema. Dor – Ao sentir aquela entrave pontiaguda entrando pelo canal da garganta e descer velozmente em direção ao estômago, é o que produz ao se deparar com um código sujo e mal feito.
Clean Code? É um código que reúne ao mesmo tempo as seguintes características:
- (^) Fácil e Simples
- Direto
- Eficiente
- Elegante
- Sem duplicidade
- Feito com cuidado
- Coeso
- Livre de verbosidade Definição de identificadores Trabalhamos a todo o momento com variáveis (de classe, de instância, local), métodos, funções, parâmetros, classes e todos eles, pelo menos há um ponto em comum. Eles devem conter nomes ou identificadores. E neste momento o desenvolvedor deve se preocupar com questões como o significado do nome para o que irá definir, e isso devem ser feito com muito cuidado e abstração. Este cuidado deve ser tomado, pois o identificador ou nome do que será definido deve transparecer:
- Seu objetivo maior (Por que existe)
- Qual sua tarefa (O que faz)
- Como é usado Ao fazer isto, use nomes que revele sua real intenção. Exemplo: int dow; // days of week Se em um código existem comentários pertinentes a descrição dele e não de um regra específica ou do por que da tomada da decisão, então ele não está revelando sua intenção. Faça distinções significativas entre os identificadores. Exemplo: for (int i = 0; i < a1.length; i++) {a2[i] = a1[i]; } Use nomes diferentes e significativos das variáveis dentro de um mesmo escopo.
Há exceções é claro, mas mesmo com exceções preze sempre pela responsabilidade única ao método. Seu nível de endentação (muitos dizem identação) não deve ser maior que 2 para uma compreensão fácil e rápida. Reforçando a regra, métodos e funções devem fazer apenas uma coisa, fazê-la eficientemente e somente fazê-la. Não economize bits, use várias palavras e as palavras certas para que o método seja facilmente entendido e possa transmitir o que ele realmente faz. Mas cuidado há boas práticas da orientação a objetos que restringe o uso de métodos com identificadores longos e que cansam o compilador.
Parâmetros Já como dizia nossa nova e já velha orientação a objetos (POO), métodos com diversos parâmetros além de confundirem quem o implementa para a chamada, devem ser evitados, exceto aqueles que se justifiquem e o por que de conter tantos parâmetros. Na orientação a objetos, como já é de se esperar trabalha-se com objetos. Assim objetos encapsulam atributos ou variáveis de instância contendo informações estritamente pertinentes a ele, assim métodos devem trabalhar com objetos como argumentos para parâmetros. Um método com uma lista grande de parâmetros além de causar todo este alvoroço, fazem com que a dificuldade de realizar testes unitários aumente.
Ainda falando de Métodos Métodos devem ter e realizar somente uma responsabilidade, e para isso existe o conceito command query separation , que diz que um método deve executar algo ou retornar algo, mas nunca as duas tarefas. DRY ( Don’t repeat yourself ) Conceito que diz, não repita código. Ou seja, evite duplicidades e reutilize ou refatore o código.
Classes A regra segue a linha de raciocínio dos métodos, que diz que devem ser pequenas e coesas, realizam somente uma responsabilidade. Classes pequenas são mais fáceis de ler e mais simples de entender. Convenções dizem que classes com tamanho superior a 200 linhas (sem um motivo claro e justificado para serem maiores) e que contem linhas com mais de 100 caracteres, é uma classe grande e que pode conter responsabilidades a mais ou distintas em seu escopo.
Ao abstrair, definir ou classificar uma classe evite usar preposições como: “e”, “mas”, “se” e “ou”, o que poderá significar que elas realizam mais que uma responsabilidade. O princípio da separação de responsabilidades (SRP) diz que uma classe deve conter apenas uma razão para ser modificada. Não há razão para ter que alterar outra classe para poder modifica-la.
Coesão Classes devem conter poucas variáveis. Cada método deve manipular uma ou mais variáveis e manter distâncias de números mágicos. Quanto mais variáveis o método manipula, mais coeso ele é para a classe. Quando há coesão, significa que métodos e variáveis são co-dependentes.
Comentários Comentários geralmente não recebem manutenção. Comentários raramente são modificados à medida que o código evolui. Há aqueles que imaginam que inserindo comentários em um código fedido, sujo e poluído, irá esconder o que já de errado nele. Comentários devem ser usados para explicar alguma tomada de decisão ou precaver e prever alguma funcionalidade anormal que poderia ser causada por alguma prática de programação já identificada anteriormente a implementação. O correto é, explique-se no código e não nos comentários. Comentários só existem para que outros desenvolvedores saibam por que causa algo foi feito daquela forma. Exemplo: // check if the employee is eligible for beneif ((employee.flags == 100) && (employee.age > 65))fits
Ao invés, use: if (employee.isEligibleForBenefits()) Comentários são úteis para mostrar a intenção por trás de uma decisão tomada, e não só pela informação.
Exemplos de comentários sem sentido e sem necessidade e muitas vezes indicando algo feito erroneamente: try {String meuStr; while (1 == 3) {i++; …
O contexto da Exception deve informar detalhes como o que aconteceu (a mensagem específica lançado pela exceção), o que estava sendo executado e o que causou o erro. Nunca utilize o tratamento da condição excepcional para dar continuidade no fluxo que foi interrompido utilizando outras funções ou métodos. Separe as regras de negócio de erros. Não retorne null quando exceções forem lançadas, procure sempre utilizar objetos especiais (Special Case Objects, Martin Fowler) ou no caso de collections ou coleções um objeto da coleção sem itens. Não passe como argumento null para métodos, é perigoso e pode causar exceções do tipo NullPonterException.
Testes Unitários Siga as três leis do TDD:
- Não escreva código antes que tenha escrito um caso de teste falhando;
- Não escreva casos de teste mais que o suficiente para falhar;
- Não implemente código além do que o suficiente para corrigir o caso de teste que estava falhando; Testes unitários não devem abranger mais que um conceito por caso, separe estes para testes em conjunto (Teste automatizado, etc). Faça com que o teste escrito seja fácil de entender, fácil de identificar. Teste F ast I ndependent R epeatable S elf-validating T imely Casos de testes devem ter execução rápida e fluída, pois cansa o desenvolver ou implementar e está propenso a não ser executado em sua completeza ou deixado de lado para eventuais reexecuções de teste. Casos de testes devem ser independentes para não influenciar ou nem causar interrupções em outros casos. Testes devem ser repetitivos e produzir o mesmo resultado. É importante estarem aptos a serem executados em diferentes ambientes. Testes devem ter um retorno que identifique que o teste falhou, não necessite de interpretação. Testes devem ser escritos antes da implementação. Após isto torna-se grande o esforço para testar. Casos de teste também devem ser limpos, e acompanhar exclusivamente a evolução do código ao qual foi escrito para verificação. São propriedades de um teste bem escrito e limpo: Manutenibilidade e Flexibilidade. O código escrito pelo teste é tão importante quanto o código da produção, pois é o teste quem garante a efetividade do código testado.
Testes nunca podem ser sentidos como um peso, ou um atraso no desenvolvimento. Testes devem ser vistos como segurança para o seu código produzido e que irá realizar o trabalho para o qual foi idealizado e designado. Mau Cheiro (Bad Smells) São exemplos de mau cheiro e que significa que seu código deve ser refatorado são:
- Comentários pobres, obsoletos e redundantes
- Código comentado
- Testes que requerem mais de um passo
- Muitos parâmetros ou parâmetros booleanos
- Métodos mortos ou que fazem muita coisa
- Responsabilidades fora do contexto
- Nomes pequenos e inexpressivos
- (^) Duplicação
- Inconsistência
- Intenção obscura
- Variáveis e funções inexpressivas
- Despadronização
- Números mágicos
- Desencapsulamento
- Efeitos colaterais
- Testes ineficientes Eles causam ao código:
- (^) (Rigidez – Uma alteração em um ponto de o código requer alterações em cascata, ou seja, o código está fortemente acoplado);
- Fragilidade – Uma alteração em um ponto do código quebras outras funcionalidades;
- Complexidade – Arquitetura muito complexa, pois foi preparada para manipular qualquer tipo possibilidade;
- Duplicação – Redundância por vários pontos do código;
- Legibilidade – Dificuldade em compreender e entender o código
