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