O que é Código Bonito?

Mauricio Anichemauricio.aniche@caelum.com.br

@mauricioanichehttp://www.aniche.com.br

O que é “bonito”?

Qual é o mais bonito?

 

Qual é o mais bonito?

 

Qual é o mais bonito?

 

simples??flexív

el?fácil de ler?

sem duplicaçõ

es?curto?

enxuto?

O que é código bonito?

Qual é o menos feio?

 

É mais fácil identificaro feio! :)

E isso pode ser útil!

métodos

longos sem padrã

o

classes

gigantes código

repetidomuitos

parâmetros

muitos if’s

“As feias que me

perdoem, mas beleza

é fundamenta

l!”

Agora vai ficar técnico!

Pensar nos nomes é importante!

Deve dizer o que ele faz, e como deve ser usado!

Tira a necessidade de lera implementação do método.

Deve ser fácil de ser entendidopor todos da equipe.

int kkk; // dias da semanaWTF?

Use nomes que

façam sentido!

public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>(); for (int[] x : theList) if(x[0] == 4) list1.add(x); return list1;}

public List<int[]> getFlaggedCells() { List<int[]> flaggedCells = new ArrayList<int[]>(); for (int[] cell : gameBoard) if(cell.isFlagged()) flaggedCells.add(cell); return flaggedCells;}

for(int i = 0; ...) { int a1 = i * 8; int a2 = a1 / 2; int a3 = (a1 + a2) * 3;}

Não crie variáveis com nomes similares!

List<Conta> contasAbertas;

@Testpublic void deve_testar_x(){}

Tenha um padrão!

List<Conta> scherobles;

Pense na língua que vai escrever.

Use nomes pronunciáveis!

E em relação aosmétodos?!

Deve ser enxuto.

Deve ter apenas umaresponsabilidade.

Deve deixar claro sua intenção.

Quantas linhas? 20? 100?

Uma página de impressora?Uma tela?

Tamanho dosmétodos

Qual o tamanho máximo?4? 8? 20?2 ifs? 3 ifs?

ComplexidadeCiclomática

Ou o método faz alguma coisa,ou ele devolve alguma coisa.

Nunca os dois.

Command QuerySeparation

O menor possível.

Mais que 3? Pense pra fazer isso.

Quantidade de parâmetros?

Evite passar “boolean” pros seus métodos.

Método faz coisa demais?

Usar flags?

Evite retornar null.

A ideia do bom vizinho.

Não retorne null!

Evite repetir código. - Extraia o que há de comum para outros métodos.

Código repetido?

Comentário de código

Somente quando necessário.

O comentário não é “código”!

Raramente são atualizados.

Comentário não é “maquiagem” de código.- Código está feio, refatora.

Código feio precisa de

comentário?

if(aluno.getQtdCursos()>10 && aluno.getMeses() > 24) { // ...}

E aquela condição

complicada?

if(aluno.isImportante()) { // ...}

O melhor é não ter.- Explicar algoritmo matemático?-Explicar alguma decisão de negócio?

Quando um comentário é

bom?

E minhas classes?

Devem ter uma única responsabilidade.

Quanto mais enxuta,mais fácil de manter e

reutilizar.

Não deve dependerde muitas outras classes.

Objetos devem ter atributos e métodos que manipulam esses atributos.

Isso é diferente de uma simples estrutura de dados.

OO from the Trenches

Pense em abstrações.

Abstrações possibilitam a evolução mais natural do código.

Estude padrões de projeto.

Abstrações são do bem

A classe deve esconder COMO ela faz sua tarefa.

Intimidade inapropriada.

Encapsule direito!

Quando bem utilizados, ajudam a flexibilizar o sistema.

“Todo mundo” conhece a solução.

Estude padrões de projeto

Tratamento de erros

Deve ser feito de maneira elegante.

Use exceções para casos excepcionais.

Não use o retorno do método para indicar se houve uma exceção.

Não use o retorno do método!

Dê contexto para sua exceção.

Se você está encapsulando a exceção, passe-a como a “causa” da sua exceção.

Exceptions caprichadas

Arquitetura?

Arquitetura vira código...

Não saia criando EJBs pra lá e pra cá...

Não tenha 200 camadas, só porque fica bonito no diagrama.

Evite arquiteturascomplicadas

demais

Não me diga que o Spring MVC / VRaptor não serve pra você...

Esqueça o seu framework

corporativo caseiro!

Não escreva regras de negócio no controller.

MVC é legal!

Controllers na Web

O que os “pops” de lá dizem?

Clean code is simple and direct. Clean code reads like wellwritten prose. (Grady Booch)

Clean code always looks it was written by someone who cares. There is nothing

obvious that you can do to make it better. (Michael Feathers)

Clean code can be read, and enhanced by a developer other than its original author.

(Dave Thomas)

O que os “pops” daqui dizem?

Código bom é o código que com o mínimo de esforço um desenvolvedor mediano do

projeto entende mesmo após o criador sair do projeto. (Guilherme Silveira)

Código bonito é código fácil e bom de ler. (Paulo Silveira)

Código que você consegue ler imediatamente, sem precisar se

esforçar. (Lucas Cavalcanti)

O que os “pops” daqui dizem?

Código feito pra pessoas lerem: tão simples quanto possível, bem separado, com nomes

decentes, etc. (Cecília Fernandes)

Código bonito é código cujos passos estão todos em um mesmo nível de abstração de forma que eu entenda claramente o melhor

ponto para alterá-lo sem ter que me preocupar se minha mudança gera impactos

inesperados. (Hugo Corbucci)

Referências

•Code Beauty. Fabio Kon. 2010.

•Clean Code. Robert Martin.

OBRIGADO!

Mauricio Anichemauricio.aniche@caelum.com.br

@mauricioanichehttp://www.aniche.com.br

http://www.tddnomundoreal.com.br