A apresentação discute os princípios de código limpo com base no livro Clean Code e experiência profissional. Os tópicos incluem nomes significativos, funções pequenas, comentários úteis, formatação consistente e uso apropriado de objetos versus estruturas de dados. O objetivo é mostrar como escrever código de alta qualidade que é fácil de manter e modificar.

1. Francisco Clauvane

2.  Esta apresentacao teve como base o livro Clean Code, a
minha experiencia profissional e as dicas dadas por
profissionais mais experientes. Onde o objetivo da
mesma e mostrar na teoria e na pratica o que e um
codigo limpo.

3.  1-Codigo limpo
 2-Nomes significativos
 3-Funcoes
 4-Comentarios
 5-Formatacao
 6-Objetos e Estrutura de dados

4.  Codigo esta ultrapassado?
 Modelos e requisitos
 Codigo gerado e nao mais escrito
 Codigo ruim
 Prazos curtos
 Lei de LeBlanc: Mais tarde e igual a nunca.
 O custo de ter um codigo confuso
 Mudanca alguma e trivial
 Produtividade baixa;Adesao de novos membros
 O grande replanejamento
 Atitude: Assumindo a culpa
 Gerentes: paixao ao prazos e requisitos;Programdores: paixao
ao codigo

5.  A arte do codigo limpo
 Analogia com a pintura de um quadro
 Disciplina para aplicar pequenas tecnicas
 Sensibilidade ao codigo
 O que e um codigo limpo?
 Multiplas definicoes
 Sensibilidade ao codigo
 Grady Booch
 Escolas de pensamento
 Analogia ao estilo de uma arte marcial
 A regra de escoteiro

6.  Nomeacoes constantes
 Use nomes que revelem seu proposito
 int d;//Tempo decorrido em dias
 int tempoDecorridoEmDias;
 Evite informacoes errradas
 int hp;//hipotenusa
 int[] accountList;
 Faca distincoes significativas
 int a1,a2,a3;
 getActiveAccount();
 getActiveAccounts();
 getActiveAccountInfo();

7.  Use nomes pronunciaveis
 private Date genymdhms;
 Use nomes passiveis de busca
 Nomes de uma letra so ou numeros possuem um
problema em particular: nao sao faceis de encontrar ao
longo de um texto;
 O tamanho de uma variavel deve ser proporcional ao
tamanho de seu escopo;
 Evite o mapeamento mental
 Contador de interacoes ser chamado de ‘b’

8.  Nome de classes
 Geralmente sao substantivos
 Ex: Conta
 Nome de metodos
 Geralmente sao nome de verbos
 Ex: salvar
 Acesso,alteracao e autenticacao
 ‘get’, ‘set’ e ‘is’
 Nao de uma de espertinho
 Use nomes serios e nao obtidos a partir de brincadeiras
que apenas um grupo limitado de pessoas saibam

9.  Uma palavra por conceito
 Fetch,retrieve e get
 Evite trocadilhos
 Use nomes a partir do dominio da solucao
 accountVisitor
 jobQueue
 Na ausencia de nomes a partir da solucao use nomes a partir
do problema.
 Adicione um contexto signigicativo
 firstName/addrFirstName
 Nao use contextos desnecessarios
 PORTALAddrFirstName/addrFirstName

10.  Devem ser pequenas
 Devem ser espertas
 Blocos e indentacoes
 If,else e while devem possuir apenas uma linha
 Estruras aninhadas devem possuir no maximo um ou
dois niveis de indentacao
 Faca apenas uma coisa
 Coesao: Principio da responsabilidade unica
 Um nivel de abstracao por funcao
 Regra decrescente

11.  Use nomes descritivos
 Melhor um nome extenso do que um pequeno e
enigmatico
 Parametros de funcoes
 Requerem muito conceito
 Ideal: sem parametros
 Monades,diades,triades e poliades
 Parametros logicos
 “Feios”: Ferem o principio da responsabilidade unica
 Alternativa: Devem ser feitas duas funcoes, uma para
cada valor logico

12.  Objetos como parametros
 Circle makeCircle (double x, double y, double radius);
 Circle makeCircle (Point center, double radius);
 Separacao comando consulta
 As funcoes devem fazer ou responder algo, mas nao ambos
 if(set(“username”, “clauvane”));
 if (setAndCheckIfExists(“username”, “clauvane”)) ;
 Prefira excecoes a retorno de codigo de errro
 Extraia os blocos try/catch
 Nao suba as excecoes para as camadas superiores, ao inves
disto extraia os blocos try/catch dentro da propria funcao
 Tratamento de erro e uma coisa so
 Nao deve existir codigo depois que o bloco try/catch termina

13.  Evite repeticoes
 Duas ou mais funcoes que se utilizam de um mesmo
trecho de codigo
 Programacao estrutura
 Regra de Edsger Dijkstra: Cada funcao e bloco dentro de
uma funcao deve ter uma entrada e uma saida.
 Somente um return, nenhum break, continue e jamais um
GOTO
 Como escrever funcoes como essa?
 Segundo Robert C. Martin: “Nao aplico desde o
comeco.Acho que isso nao seja possivel”

14.  Comentarios compensam um codigo ruim
 Motivacao para fazer a bagunca
 Explique-se no codigo
 Comentarios bons
 De maneira geral, comentario bom e aquele que nao precisa
ser escrito
 Gerados automaticamente
 Informativos
 Explicacao da intencao
 Alerta sobre consequencias
 //TODO
 Destaque
 Javadocs

15.  Comentario ruins
 Redundantes
 Enganadores
 Imperativos
 Toda funcao deve ter um javadoc.
 Longos
 Ruidosos (Obvios)
 Evite o comentario se e possivel usar uma funcao ou
variavel
 Marcadores de posicao
 Se usados esporadicamente e em situacoes que seja justificado
sua existencia (sensibilidade ao codigo) nao ha problemas

16.  Comentarios ao lado de chaves de fechamento
 Usado em funcoes grandes
 Ao inves de usar um comentario para suprir a necessidade de
compreensao da funcao, voce deve diminuir esta funcao
 Credito e autoria
 Desnecessarios
 Versionamento de codigo
 Codigo como comentario
 Medo
 Versionamento de codigo
 Comentario HTML
 Tarefa da ferramenta e nao do programador

17.  Informacoes nao-locais
 Comentario devem estar proximos ao codigo que e descrito
 Informacoes excessivas
 Conexoes com o codigo
 O comentario deve esta conectado ao codigo o suficiente para
que o proximo leitor seja capaz de entende-lo
 Cabecalhos de funcoes
 Melhor usar um bom nome do que um comentario de
cabecalho
 Javadoc em codigos nao-publicos
 Diferentemente dos codigo publicos os javadoc dos nao-
publicos sao horriveis

18.  Objetivo da formatacao
 Comunicao de qualidade entre os programadores
 Vertical
 Tamanho da classe em linhas
 Metafora do jornal
 Nivel de abstracao vai do topo para baixo
 Espacamento vertical entre os conceitos
 Uma linha em branco
 Distancia vertical
 Os conceitos intimamentes ligados devem ficar juntos
verticalmente
 Declaracao de variaveis,variaveis de instancia,funcoes dependentes
 Afinidade conceitual
 Ordenacao vertical
 A funcao chamada deve ficar abaixo da que a chama

19.  Horizontal
 Tamanho da linha
 Espacamento e continuidade horizontal
 Um espaco em branco
 Alinhamento Horizontal
 Nao e pratico
 Indentacao
 No maximo uma ou duas

20.  Abstracao de dados
 Concreto
 Estrutura de dados
 Abstrato
 Objeto
 A lei de Demeter
 Um modulo nao deve enxergar o interior de um objeto que ele
manipula.
 Train wrecks (Acidentes ferroviarios)
 String coisa = getCoisa().getAlgumaCoisa().getOutraCoisa();
 Violacao a lei de Demeter
 Hibridos
 Metade Objeto metade estrutura de dados
 Objetos de transferencia de dados (DTOs)
 beans

21.  Active record
 DTOs com metodos de navegacao
 Sao estrutura de dados
 Muitos o tratam como objeto e acabam o tornando num
hibrido

22.  Sites e livros recomendados
 http://www.guj.com.br
 http://www.CasaDoCodigo.com.br
 http://www.caelum.com.br/online
 https://github.com/clauvane
 https://github.com/rponte
 O livro Clean Code de Robert C. Martin