clean code em c#

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: gustavobr1989@gmail.com

- GitHub: @gustavoaraujo

- Linkedin e Facebook: @ogustavoaraujo