cleaner-code-centralit-2015

1 de 80www.centralit.com.br | [email protected]

Cleaner CodePor um mundo com menos xingamentos


O LIVRO

Robert C. Martin (Uncle Bob)

Programador desde 1970;

Fundador e Presidente Object

Mentor Inc.

lDesigning Object-Oriented C++

Applications using the Booch

Method. 1995.

lAgile Software Development:

Principles, Patterns and Practices.

2002.


SonarQube

“É uma ferramenta opensource para análise egerenciamento de qualidade de código queoferece um relatório visual e a evoluçãohistórica do código.”

www.sonarqube.org


Situação

Quem nunca pegou um código que deverialevar horas e levou semanas para ser corrigido?

Manter o código mais limpo possível.

10de 80www.centralit.com.br | [email protected]

Isso é preocupante pra nós?

Toda vez que você escreve um Bad Code, vocêestá fazendo parte do problema.


Médico e Paciente


Evolução contínua


Clean Code

”Qualquer um consegue escrever código queum computador entende. Bons programadoresescrevem código que humanos entendem.”

Martin Fowler


Como conquistar isso?


Single Responsibility Principle(SRP)

”Uma classe deve ter um, e apenas um, motivopara ser modificada. Esse princípio também échamado de coesão e implica em dizer que umaclasse deve fazer uma única coisa e fazê-labem.”


Princípio Don't Repeat Yourself (DRY)

”A duplicação (seja ela acidental ou proposital)pode levar a pesadelos de manutenção, alémde atrapalhar a refatoração e gerarcontradições lógicas.”


Nomes Significantes

•Leva tempo, mas ajuda muito mais.•Teremos programadores mais felizes.•Deve-se dizer o que faz, por que existe e comousá-la.•Se precisar de comentários, não é um nomesignificante.


Nomes Significantes


Utilize nomes buscáveis para números e StringsEx.: X = 20para X = VALOR_HORA;


Encapsule condições

Lógica booleana já é difícil o bastante entender.Se não vier dentro de um contexto de um if ouwhile.



Evite condições negativas. Elas são um poucomais difíceis de entender. Quando possível,deveria ser expressado como positiva.


Utilize Enums ao invés de Constantes


Nome de Classes e Métodos

Classes Pronomes. Ex.: Paciente, WikiPage, Conta.

•Métodos Verbos: deletar, postar, curtir, desenhar.


Sobrecarga de Construtores

Utilize métodos estáticos que descrevam os argumentos.


Escolha uma palavra por Conceito

Ex.: Buscar..., recuperar..., get..., pegar...

Não use mesmo termo para coisas distintas.


Métodos

•Regra 1: Deveriam ser pequenas.•Regra 2: Deveriam ser menores do que isso.

•O quanto pequeno deveria ser? (linhas)

De duas a cinco linhas.


Blocos e Identação

If, else e while deveriam ter apenas uma linha de código, provavelmente uma função.



Mantém pequeno e adiciona valor de documentação, por que a função pode ter um bom e descritivo nome.



Métodos curtos tendem a fazer uma coisa por vez, adicionando coesão.


Switches

Grandes, quebram o SRP e se um novo tipo for adicionado irá crescer mais.


Switches

Solução: Definir o switch em uma classe abstrata e “não deixar ninguém ver”. Utilizar polimorfismo.


Princípio de Ward

“Você sabe quando está trabalhando em um clean code quando cada rotina/método/classe faz o que realmente você espera.”


Argumentos de métodos

Ideal: ZERO.Quantidade de parâmetros superior a 3 devem ser evitados e quando utilizados devem ser justificados.


Argumentos de métodos

São difíceis de entender e de testar.


Métodos com UM argumento

Você faz uma pergunta sobre o argumento.



Opera em cima desse argumento, transformando-o em outra coisa.

InputStream fileOpen(“nome_arquivo”);


Argumentos FLAG

São feios. Não é uma boa prática, além de declarar que o método tem mais de uma responsabilidade.


Argumentos FLAG


Métodos com DOIS argumentos

Mais difícil de entender, mas as vezes é OK.

Ex.: new Point(0,0);


Métodos com DOIS argumentos

As vezes pode levar ao erro.

Ex.: assertEquals(expected, actual);


Métodos com TRÊS argumentos

Utilizar objetos/classes como argumento.



Utilizar objetos/classes como argumento.

Ex.: Pega exemplo do nome social


Métodos

Qualquer método que faça você verificar a declaração ou sua implementação, seria um tempo desperdiçado.


Métodos

Funções deveriam fazer ou perguntaralgo. Mudar o estado do objeto ou retornar alguma informação sobre ele e não os dois.


Exceptions

Prefira Exceptions à códigos de erro.


Exceptions – Códigos de erro

São feios, confundem a estrutura de código com o processo/tratamento de erro.


Exceptions – Exceções

Fornece uma ótima separação do que o código faz, deixando fácil de entender e de modificar.


Exceptions – Boas práticas

Utilize try-catch primeiro.Catch tem que deixar o sistema consistente.


Exceptions – Boas práticas


Exceptions – Não retorne NULL

lPrefira lançar uma Exception ou retornar um objeto especial ao invés de NULL.


Exceptions – Não retorne NULL

lNão tem boas práticas para tratar NULL. A forma racional de tratar isso é não passar/retornar null.


Exceptions

Utilize unchecked exception.


Comentários

Não comente código ruim, reescrevá-os.

Comentários não ajudam um código sujo! Emgeral, servem para explicar um código ruim.


Comentários

Comentários são compensações para nossas falhas em nos expressar no código.


Comentários

Se você acha que precisa escrever um comentário, tente pensar novamente e expresse o que você quer no código.


Por que comentários são ruins?

Por que eles mentem. Não sempre e não intencionalmente, mas com muita frequência.


Noise Comments

Get's / Set'sConstrutores padrãoGerados pela IDE


Comentário Informativo

Retorno de métodos abstratos.TODO's.Ampliar a importância em algo, API

Públicas.


Positions Markers

lEx.: // Actions //////////////////


Positions Markers


Comentários

Pessoas não deletam isso. Eles pensam que existe uma razão que é muito importante para não deletá-los


Comentários


Classes

lDeveriam ser pequenas. O quanto pequenas? Não pequenas em quantidade de linhas, mas em responsabilidades.


Classes

lO nome da classe deve descrever quais responsabilidades está preenchida. Nós deveríamos descrever uma classe com +-25 palavras, sem usar Se, e, ou, mas...


Classes

lUma classe deve ser aberta para extensão e fechado para modificação.


Design Simples

lExecute todos os testes.lRemova duplicações.lExpresse a intenção do programador.lMinimize o número de classes e métodos.


REGRA DOS ESCOTEIROS

Deixe a área do acampamentomais limpa do que como vocêa encontrou.


Finalmentes

•Os nomes devem ser pronunciáveis.•Evite encodings.


Finalmentes

Não tenha medo de mudar código. Seremos gratos quando você mudar (para melhor!). Seguir essas regras e melhorar a leitura do seu código é um valor que será pago a curto e a longo prazo.


Mensagem

Redefina o código, divida funções, mude nomes, elimine duplicações, deixe os métodos curtos e reordene-os.


Obrigado!E-Mail

[email protected]

cleaner-code-centralit-2015

Documents