clean code clickbus
DESCRIPTION
TRANSCRIPT
What about Clean Code?
Marcelo Santos - @marcelsud
What about Clean Code?“It is not enough for code to work.”
Robert C. Martin (Uncle Bob)
● Código duplicado● Classes longas (se houver)● Parâmetros demais● Falta de testes (ou nenhum)● Falta de Coding Standards● No design patterns at all● Código morto● Alta curva de aprendizado● Uma alteração, vários bugs● Alocação de mais recursos● Elevado custo em manutenção● Queda de produtividade● Perda de performance● Remendos / Gambiarras● ...
Consequências de código ruim
A Regra do Escoteiro
“Deixe a área do acampamento mais limpa do que como você a encontrou”
Boy Scouts of America
Nomes significativos
Como?
● Pronunciáveis● Que revele seu propósito
Onde?
● Variáveis● Métodos
● Parâmetros● Classes
● Namespaces● etc
Nomes ruins
Nomes melhores
Parâmetros demais
Os métodos devem ter um número pequeno de parâmetros. Nenhum é o ideal.
Acima de três é questionável.
Parâmetros demais
Poucos parâmetros
Comentários
Comentários
"Não insira comentários num código ruim, reescreva-o"Brian W. Kernighan e P. J. Plaugher
Não faça isso…
Lembre-se...
Se você precisa esclarecer seu código com um comentário, talvez seja um bom momento para
revê-lo.
Duplicação
DRY: Don’t Repeat Yourself
Sempre que você vir duplicação em código, isso significa que você perdeu uma chance para abstração.
Encontre e elimine duplicações sempre que puder!
Código morto
● Variáveis não utilizadas● Pedaços de código inúteis
● Comentários que não acrescentam informações
Faça a coisa certa: Dê a eles um funeral decente!
Flag Arguments
“Argumentos Booleanos claramente declaram que o método possui mais que uma responsabilidade. Eles
são confusos e devem ser eliminados.”Uncle Bob
Flag Arguments
Flag Arguments
Encapsular condicionais
melhor que...
Substituir números mágicos por constantes
melhor que...
Evitar condicionais negativas
melhor que...
Coding Standards
“Softwares são feitos para ser lidos por humanos, e somenteincidentemente para ser executados por computadores”
H. Abelson and G. Sussman
Tratamento de erros
● Evitar retornar um código de erro● Lançar excessões com contexto
● Não retornar NULL● Utilizar mensagens informativas
Testes unitários
Fast: Devem ser rápidos.Independent: Sem depender uns dos outros e na hora que desejar.Repeatable: Devem passar tanto no servidor, quanto num notebook sem wi-fi.Self-validating: Devem garantir o resultado sem intervenção manual.Timely: Devem ser criados antes do código.
LoD: Law of DemeterDesign by Contract
Design PatternsOrthogonality
CohesionSOLID
Classes
SOLID
SRP: Single responsibility principlea class should have only a single responsibility.
OCP: Open/closed principle“software entities … should be open for extension, but closed for modification”.
LSP: Liskov substitution principle“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”
ISP: Interface segregation principle“many client-specific interfaces are better than one general-purpose interface.”
DIP: Dependency inversion principleone should “Depend upon Abstractions. Do not depend upon concretions.”
Classes
KISS: Keep it simple, stupid!
"A perfeição é alcançada não quando não há mais nada para adicionar,mas quando não há mais nada que se possa retirar"
Antoine de Saint-Exupéry, autor de "O Pequeno Príncipe"
Toda complexidade desnecessária deve ser descartada.
What about Clean Code?
Marcelo Santos - @marcelsud