Francisco Clauvane

Esta apresentacao teve como base o livro Clean Code, a minha experiencia profissional e as dicas dadas porprofissionais mais experientes. Onde o objetivo damesma e mostrar na teoria e na pratica o que e um codigo limpo.

1-Codigo limpo

2-Nomes significativos

3-Funcoes

4-Comentarios

5-Formatacao

6-Objetos e Estrutura de dados

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

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

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();

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 aolongo de um texto;

O tamanho de uma variavel deve ser proporcional aotamanho de seu escopo;

Evite o mapeamento mental Contador de interacoes ser chamado de ‘b’

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

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

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 oudois niveis de indentacao

Faca apenas uma coisa Coesao: Principio da responsabilidade unica

Um nivel de abstracao por funcao

Regra decrescente

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

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

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”

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

Comentario ruins Redundantes Enganadores Imperativos

Toda funcao deve ter um javadoc.

Longos Ruidosos (Obvios)

Evite o comentario se e possivel usar uma funcao ouvariavel

Marcadores de posicao Se usados esporadicamente e em situacoes que seja justificado

sua existencia (sensibilidade ao codigo) nao ha problemas

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

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

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

Horizontal Tamanho da linha

Espacamento e continuidade horizontal Um espaco em branco

Alinhamento Horizontal Nao e pratico

Indentacao No maximo uma ou duas

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

Active record DTOs com metodos de navegacao

Sao estrutura de dados

Muitos o tratam como objeto e acabam o tornando num hibrido

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