Clean Code em C#
Gustavo Araujo@ogustavoaraujo
Sobre o C#
• Microsoft – 2001.
• Criada como parte da plataforma .NET
• Baseada em C, C++, Java
• Indice Tiobe: 4º lugar
Características do C#
• Interpretada: código é executado por um interpretador, que em seguida é executado pelo sistema operacional ou processador.
• Fortemente tipada: todas as variáveis tem um tipo específico e seus tipos são importantes para a linguagem.
Características do C#
• Simplicidade: linguagem tão poderosa quanto o C++ e tão simples quanto o Visual Basic.
• Completamente orientada a objetos: em C#, qualquer variável tem de fazer parte de uma classe.
Características do C#
• Tudo é um objeto: System.Object é a classe base de todo o sistema de tipos de C#.
• Controle de versões: cada assembly gerado, seja como EXE ou DLL, tem informação sobre a versão do código, permitindo a coexistência de dois assemblies homônimos, mas de versões diferentes no mesmo ambiente.
Sobre o Clean Code• Marco inicial: “Clean Code: A Handbook of
Agile Software Craftmanship”, Robert C. Martin.
Sobre o Clean Code
• Eficiente (YAGNI – You ain’t gonna need it)• Simples (KISS – Keep it simple, stupid!)• Direto• Sem redundâncias (DRY – Don’t repeat
yourself)• Fácil de ler, entender e manter• Objetivo: evitar Code Smells (indícios de erros
no Código-Fonte)
Regra do Escoteiro
• Deixe o lugar mais limpo do que estava quando você chegou.
Teoria das Janelas Quebradas
• James Wilson e George Kelling, 1982.
• Onde algo está desorganizado, há a tendência de que aquilo se torne cada vez mais desorganizado com o tempo.
Consequências
• Menor ocorrência de bugs• Mais fácil de editar• Mais rápido de carregar• Economia de tempo/dinheiro
Princípios
Nomes significativos
“Td v a p qd a al n é pq”
Nomes significativos
“Tudo vale a pena quandoa alma não é pequena”
Nomes significativos
• Funciona? Funciona.• É o melhor? Não necessariamente.
Nomes significativos
Nomes significativos
• Fácil entendimento do que é uma variável, um método, uma classe.
• Ajuda na manutenção de sistemas - escala.
• Nomes que revelem a intenção.
Nomes significativos
• Nomes pronunciáveis.
Nomes significativos
• Evitar nomes muito parecidos.
Nomes de classes e métodos
• Classes: substantivos começando com letra maiúscula. Ex.: Aluno, Faculdade.
• Métodos: verbos/frases curtas começando com letra maiúscula. Ex.: EfetuarDivisao, CadastrarAluno, Buscar.
Nomes de classes e métodos
• Na hora de chamar...
Nomes de classes e métodos
• Na hora de chamar...
UM MÉTODO SÓ DEVE CUMPRIR UMA FUNÇÃO.
Juro que não quero ser redundante ao dizer isso, mas...
Métodos
Métodos
• Como saber se um método faz somente uma coisa?
– Verifique se é possível extrair outro método que não seja uma reafirmação da implementação inicial.
Refactoring
• Reorganização do código, de modo que melhore a estrutura interna, sem modificar seu comportamento externo.
Métodos (refactoring)
Métodos (refactoring)
Nomes inconsistentes de métodos
• Relação entre nomes de classes, de modo que haja coesão de idioma e de significado.
Parâmetros• Evitar parâmetros que possam ser extraídos
dentro do método.• Muitos parâmetros atrapalham na reutilização
do código.
Parâmetros
Indentação
Indentação
Ordem dos métodos
• Execução: de cima para baixo.
• Método principal primeiro.
• Lembrar disso quando criar métodos privados – refatorações.
Ordem dos métodos
Ordem dos métodos
Condicionais• Evitar condicionais longos.
Variáveis
• Evitar muitas variáveis.• Variáveis booleanas, no geral, não são boas.
Variáveis
Nome do tipo na variável
• Não fazer! Nome do tipo na variável pode ser um problema principalmente se, por uma alteração no sistema, o tipo de resultado esperado muda.
Comentários
• Comentários não limpam um código sujo.
Comentários
• Uso de summary
Comentários
• Uso de summary
Comentários
• São recomendados:– Sobre licença de uma lib.– Informativos.– Explicação – regras de negócio.
• Devem ser evitados:– Redundantes.– Dizem o que o código deveria dizer.
Exceções
• Usar mensagens de erro.
Exceções
Regiões
• Recomendadas para guardar métodos.
Regiões
• Não-recomendadas para esconder comandos dentro dos métodos.
Código morto
• Código que não está sendo utilizado pelo programa. Deve ser eliminado.
God object (classe extensa)• Quando uma classe contém muitos métodos,
ela pode ser refatorada em outras classes.
Métodos e classes preguiçosos
• Métodos e classes que fazem pouca coisa.
Exposição Indecente• Acontece quando usa-se o nível de permissão
indevido para um método.
Exposição Indecente
Oddball Solution (solução excêntrica)
• Quando um mesmo problema é resolvido de duas maneiras diferentes no mesmo código, sendo uma mais excêntrica que outra.
• Uma só passa a ser usada, podendo se tornar um método a ser usado em ambas as situações.
Oddball Solution
Refused Bequest (Legado Recusado)
• Acontece quando uma classe recebe métodos da outra, mas não os implementa.
Lei de Demeter
• Karl Lieberherr e Ian Holland, 1987, Boston University.
• Diminui o acoplamento de classes
• Melhora a manutenibilidade do código
Princípios da Lei de Demeter
• Um método A de um objeto O somente poderia acessar métodos de outros objetos segundo as seguintes regras:– Seja um parâmetro de A;– Seja um objeto que A criou;– Seja um método do próprio objeto O;– Seja um objeto diretamente relacionado com o
objeto O;– Seja uma variável global acessível ao objeto O;
Lei de Demeter – exemplo do cachorro
• Quando você precisa que um cachorro ande, você dá a ordem para as pernas diretamente, ou para o cachorro? Obviamente que para o cachorro e este sabe o que precisa ser acionado para andar.
Exemplo da Lei de Demeter
Exemplo da Lei de Demeter
Essa não é a maneira apropriada, de acordo com a Lei de Demeter, por buscaro valor de um objeto dentro de outro.
Exemplo da Lei de Demeter
DRY (Don’t Repeat Yourself)
DRY (Don’t Repeat Yourself)
Clean Code para Testers
• Três coisas são importantes para manter um teste limpo:– Legibilidade– Legibilidade– Legibilidade
Clean Code para Testers
• Variáveis hard-coded: cujo valor está fixo dentro do código.
Clean Code para Testers
O que faz um código ser limpo?
• Lógica direta (evita encobrimento de bugs)• Dependências mínimas• Tratamentos de erro• Métodos celulares• Nomes significativos• Sem duplicações
CALMA, O VISUAL STUDIO TE AJUDA.
Como saber por meio de métricas se eu preciso refatorar meu código?
Visual Studio – Code Metrics• Ferramenta nativa de diagnóstico, define
métricas para análise de código.• Analyze > Calculate Code Metrics.• Pode analisar solução ou projeto.
Maintainability Index
• Índice de 0 a 100.• Determina o grau de facilidade de
manutenção do código.
Cyclomatic Complexity
• Vai de 1 a >51.• Se a complexidade ciclomática é baixa, logo
existem menos caminhos para testar (menos if's desviando o caminho, por exemplo) e, por isso, um número baixo para a complexidade ciclomática NÃO faz os testes serem mais complexos. Complexidade ciclomática baixa leva a uma maior facilidade para testar. Se muito alta a cobertura do teste será insuficiente.
Depth of Inheritance
• Nível de herança – árvore.
• Toda classe começa do 1 – herda do System.
• Quanto mais próximo do 1, melhor. Quanto mais próximo do System, mais fácil prever comportamentos.
Depth of Inheritance
• Porém, isso é relativo. Um baixo número de heranças pode significar pouco reaproveitamento de código.
Class Coupling
• Acoplamento entre classes. Quanto menor, melhor.
• Dependência de funcionamento.
Lines of Code
• Quantidade de linhas de código por classe/solução. Quanto menor a quantidade, mais fácil de testar e menos complexo é um código.
Plugins – Visual Studio
• StyleCop - https://stylecop.codeplex.com/
• Resharper - https://www.jetbrains.com/resharper/
• CodeMaid - http://www.codemaid.net/
Obrigado!
- E-mail: [email protected]
- GitHub: @gustavoaraujo
- Linkedin e Facebook: @ogustavoaraujo
Top Related