O documento discute princípios de clean code em C#, incluindo nomes significativos, métodos simples, baixo acoplamento entre classes e redução de duplicação de código. O Visual Studio fornece ferramentas como Code Metrics para medir a qualidade do código e identificar áreas que precisam de refatoração.

1. Clean Code em C#
Gustavo Araujo
@ogustavoaraujo

2. Sobre o C#
• Microsoft – 2001.
• Criada como parte da plataforma .NET
• Baseada em C, C++, Java
• Indice Tiobe: 4º lugar

3. 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.

4. 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.

5. 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.

6. Sobre o Clean Code
• Marco inicial: “Clean Code: A Handbook of
Agile Software Craftmanship”, Robert C.
Martin.

8. 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)

9. Regra do Escoteiro
• Deixe o lugar mais limpo do que estava
quando você chegou.

10. 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.

11. Consequências
• Menor ocorrência de bugs
• Mais fácil de editar
• Mais rápido de carregar
• Economia de tempo/dinheiro

12. Princípios

13. Nomes significativos
“Td v a p qd a al n é pq”

14. Nomes significativos
“Tudo vale a pena quando
a alma não é pequena”

15. Nomes significativos
• Funciona? Funciona.
• É o melhor? Não necessariamente.

16. Nomes significativos

17. 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.

18. Nomes significativos
• Nomes pronunciáveis.

19. Nomes significativos
• Evitar nomes muito parecidos.

20. 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.

21. Nomes de classes e métodos
• Na hora de chamar...

22. Nomes de classes e métodos
• Na hora de chamar...

23. UM MÉTODO SÓ DEVE CUMPRIR
UMA FUNÇÃO.
Juro que não quero ser redundante ao dizer isso, mas...

24. Métodos

25. 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.

26. Refactoring
• Reorganização do código, de modo que
melhore a estrutura interna, sem modificar
seu comportamento externo.

27. Métodos (refactoring)

28. Métodos (refactoring)

29. Nomes inconsistentes de métodos
• Relação entre nomes de classes, de modo que
haja coesão de idioma e de significado.

30. Parâmetros
• Evitar parâmetros que possam ser extraídos
dentro do método.
• Muitos parâmetros atrapalham na reutilização
do código.

31. Parâmetros

32. Indentação

33. Indentação

34. Ordem dos métodos
• Execução: de cima para baixo.
• Método principal primeiro.
• Lembrar disso quando criar métodos privados
– refatorações.

35. Ordem dos métodos

36. Ordem dos métodos

37. Condicionais
• Evitar condicionais longos.

38. Variáveis
• Evitar muitas variáveis.
• Variáveis booleanas, no geral, não são boas.

39. Variáveis

40. 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.

41. Comentários
• Comentários não limpam um código sujo.

42. Comentários
• Uso de summary

43. Comentários
• Uso de summary

44. 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.

45. Exceções
• Usar mensagens de erro.

46. Exceções

47. Regiões
• Recomendadas para guardar métodos.

48. Regiões
• Não-recomendadas para esconder comandos
dentro dos métodos.

49. Código morto
• Código que não está sendo utilizado pelo
programa. Deve ser eliminado.

50. God object (classe extensa)
• Quando uma classe contém muitos métodos,
ela pode ser refatorada em outras classes.

51. Métodos e classes preguiçosos
• Métodos e classes que fazem pouca coisa.

52. Exposição Indecente
• Acontece quando usa-se o nível de permissão
indevido para um método.

53. Exposição Indecente

54. 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.

55. Oddball Solution

56. Refused Bequest (Legado Recusado)
• Acontece quando uma classe recebe métodos
da outra, mas não os implementa.

57. Lei de Demeter
• Karl Lieberherr e Ian Holland, 1987, Boston
University.
• Diminui o acoplamento de classes
• Melhora a manutenibilidade do código

58. 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;

59. 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.

60. Exemplo da Lei de Demeter

61. Exemplo da Lei de Demeter
Essa não é a maneira apropriada, de acordo com a Lei de Demeter, por buscar
o valor de um objeto dentro de outro.

62. Exemplo da Lei de Demeter

63. DRY (Don’t Repeat Yourself)

64. DRY (Don’t Repeat Yourself)

65. Clean Code para Testers
• Três coisas são importantes para manter um
teste limpo:
– Legibilidade
– Legibilidade
– Legibilidade

66. Clean Code para Testers
• Variáveis hard-coded: cujo valor está fixo
dentro do código.

67. Clean Code para Testers

68. 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

69. CALMA, O VISUAL STUDIO TE
AJUDA.
Como saber por meio de métricas se eu preciso refatorar meu código?

70. 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.

71. Maintainability Index
• Índice de 0 a 100.
• Determina o grau de facilidade de
manutenção do código.

72. 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.

73. 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.

74. Depth of Inheritance
• Porém, isso é relativo. Um baixo número de
heranças pode significar pouco
reaproveitamento de código.

75. Class Coupling
• Acoplamento entre classes. Quanto menor,
melhor.
• Dependência de funcionamento.

76. 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.

77. Plugins – Visual Studio
• StyleCop - https://stylecop.codeplex.com/
• Resharper - https://www.jetbrains.com/resharper/
• CodeMaid - http://www.codemaid.net/

78. Obrigado!
- E-mail: gustavobr1989@gmail.com
- GitHub: @gustavoaraujo
- Linkedin e Facebook: @ogustavoaraujo