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