• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clean code
 

Clean code

on

  • 980 views

 

Statistics

Views

Total Views
980
Views on SlideShare
943
Embed Views
37

Actions

Likes
4
Downloads
21
Comments
0

3 Embeds 37

http://www.enthuse.me 19
http://www.linkedin.com 16
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Clean code Clean code Presentation Transcript

  • CLEAN CODE escrevendo código limpo
  • DISCLAIMER
  • OVERVIEW
  • SOBRE O QUE FALAREI• nomenclaturas • objetos• funções • estrutura de dados• classes • tratamento de exceções• formatação • boundaries• comentários • unit testing
  • SOBRE O QUE NÃO FALAREI • dependency injection • emergência • TDD • concorrência • refactoring • frameworks de teste
  • fonte: http://www.osnews.com/story/19266/WTFs_m
  • O QUE É UM CÓDIGO LIMPO?• direto ao ponto • padrões definidos• mínimas dependências • de fácil leitura/entendimento• sem duplicação • coberto de testes• fácil manutenção • elegante sindrome da janela quebrada
  • “NÃO SOU UM EXCELENTE DESENVOLVEDOR. SOU APENASUM DESENVOLVEDOR MEDIANO QUE SEGUE À RISCA AS BOAS PRÁTICAS DE UM CÓDIGO LIMPO.” (um dev muito famoso)
  • NOMES SIGNIFICATIVOS
  • NOMES SIGNIFICATIVOS Se o nome requer um comentário, é um nome ruim
  • USEM NOMES QUE REVELEM A INTENÇÃO
  • NOMES SIGNIFICATIVOS 1. What kinds of things are in theList? 2. What is the significance of the zeroth subscript of an item in theList? 3. What is the significance of the value 4? 4. How would I use the list being returned?
  • USEM NOMES PRONUNCIÁVEIS
  • NOMES SIGNIFICATIVOS 1. Parte do nosso cérebro é dedicado ao conceito de palavras. e palavras, por definição, são pronunciaveis; usemos essa parte do cérebro! 2. Programar é uma atividade social. 3. método Dê tê á Érre Cê Dê
  • USEM NOMES BUSCÁVEIS
  • NOMES SIGNIFICATIVOS 1. Muito mais facil encontrar WORK_DAYS_PER_WEEK DO QUE “5” 2. “SUM” não é de fato um nome muito útil, mas ao menos já é mais buscável do que simplestemente “s” 3. CODE SMELL! MAGIC NUMBER!
  • TAMBÉM NOMEAMOS CLASSES E MÉTODOS
  • NOMES SIGNIFICATIVOSCLASSESem geral, classes devem ser representadas por substantivos, não verbos.bons exemplos: Cliente, Perfil, Estoque, etc.MÉTODOSem geral, métodos devem ser representadas por verbos ou frases verbaisbons exemplos: enviarPagamento, removerPagina, salvar, etc. (prefira o infinitivo)
  • NÃO SEJA PIADISTA :)
  • FUNÇÕES
  • SEJA PEQUENO
  • FUNÇÕES• menos é sempre mais!• extraia trechos em métodos privados• lembre-se dos nomes significativos ;)• vá direto ao ponto
  • FUNÇÕES
  • FAÇA UMA ÚNICA COISAblocos e endentação,indicios de que estáfazendo muita coisa
  • FUNÇÕES• repare a endentação (sim, é assim que escreve ;)• muitos níveis ~= muita responsabilidade•o método deve fazer uma única coisa, e bem!• dá para extrair? está fazendo mais de uma coisa
  • LEIA O CÓDIGO DE CIMA PARA BAIXOComo uma narrativa
  • FUNÇÕES• seu código deve ser lido como uma narrativa• temos sujeitos, verbos e predicados :)• narrativas são frases com uma ordem coerente• lembre-se disso ao extrair em métodos privados
  • FUNÇÕES E SEUS ARGUMENTOS
  • FUNÇÕES• muitos argumentos ~= code smell• existem algumas regras para qtd de argumentos• argumentos booleanos em geral não são bons• ex:
  • FUNÇÕES
  • EVITE OS SIDE EFFECTS
  • FUNÇÕES Onde está o side effect?
  • EXCEÇÕES SÃO MELHORES QUE CÓDIGOS DE ERRO
  • FUNÇÕES
  • DRY (DON’T REPEAT YOURSELF)
  • COMENTÁRIOS devem valer os bytes que consomem
  • COMENTÁRIOS NÃO AJUDAM UM CÓDIGO SUJO
  • COMENTÁRIOS “Ooh, I’d better comment that!” No! You’d better clean it!• em geral, servem para explicar um código ruim• um bom código é auto-documentado• extraia para um método que faça o que diz!
  • COMENTÁRIOS ACEITÁVEIS
  • COMENTÁRIOS // format matched kk:mm:ss EEE, MMM dd, yyyy Pattern timeMatcher = Pattern.compile( "d*:d*:d* w*, w* d*, d*");• comentários sobre licença• comentários informativos• necessidade de explicação de intenção (negócio)
  • COMENTÁRIOS RUINS
  • COMENTÁRIOS // format matched kk:mm:ss EEE, MMM dd, yyyy Pattern timeMatcher = Pattern.compile( "d*:d*:d* w*, w* d*, d*");• por falta do que escrever• redundantes• doc em APIs não-públicas• dizendo algo que o próprio código deveria dizer• código comentado :/
  • COMENTÁRIOS
  • FORMATAÇÃOpode ser interpretadocomo uma coisa pessoal.apesar disso, valem ospadroes entre times
  • O QUE VALE É A REGRA DO TIME
  • MAS EXISTEM ALGUNS PADRÕES DE LINGUAGENS
  • PYTHON: PEP8explicar o pq da PEP 8, é sempre bom saber qual existem padroes parasua importância para o padrão da linguagem. nomes de classe, nomespessoas que vão ler o python tem um padrão, de modulo, nomes decodigo, etc. Java tem outro, C++ tem metodos, variaveis, outro constantes, etc.
  • E JAVASCRIPT?
  • LIMITES HORIZONTAIS explicar o pq da linha de limite horizontal.
  • ENDENTAÇÃO, QUEBRA DE LINHAS E TERNÁRIOS
  • E O IDIOMA?leve em consideracao alinguagem de dominio. porexemplo, ficariaestranho traduizer“Folião”
  • OBJETOS E ESTRUTRA DE DADOS
  • ABSTRAÇÃO DE DADOS
  • OBJETOS E ESTRUTURAS DE DADOS• objetos expõem comportamentos e escondem dados• estruturas de dados expõem seus dados e não têm comportamentos significativos
  • A LEI DE DEMETER
  • OBJETOS E ESTRUTURAS DE DADOS• um método f de uma classe C só conhece: • métodos de C • objetos criados por f • objetos passados como argumentos para f • objetos em variáveis de instância de C
  • vagão de trem
  • TRATAMENTO DE ERRO
  • EXCEÇÕES AO INVÉS DE CÓDIGO DE ERRO ;)
  • TRATAMENTO DE EXCEÇÃO É UMA DAS COISAS QUE UMA FUNÇÃO/MÉTODO FAZ try except finally deve ser o unico bloco de um metodo
  • NÃO USE EXCEÇÕES GENÉRICAS conheça seu código. saiba que tipos de exceções podem ser disparadas. se nao conhece as exceções default, dê uma lida nelas
  • VOCÊ TAMBÉM PODE CRIAR EXCEÇÕES! se couber fazer uma exceção especifica, crie uma classe de Excecao sua que será usada em outros pontos do projeto
  • NÃO RETORNE NULL - obriga usos de if - pode disparar nullpointer - considere lancar uma exceção ou retornar um objeto especial
  • NÃO PASSE NULL- obriga tratamento de nulo- tira a legibilidade do códigoalgumas linguagens até facilitam
  • CLASSES
  • BASICAMENTE AS MESMAS DICAS DE FUNÇÕES ;)
  • PARTIU ALMOÇAR? :D
  • MUITO OBRIGADO @gustavocsb