SlideShare uma empresa Scribd logo
25ª Semana da Tecnologia
da Fatec Sorocaba
<Juliana Fideles>
{ gerente de projetos • full stack developer }
Quemsoueu?
• Formada em Análise e Desenvolvimento de Sistemas
pela Fatec Sorocaba e pós-graduada em
gerenciamento de projetos pelo Senac Sorocaba.
• Possui mais de 6 anos de experiência na área de
tecnologia da informação. Mais de 2 anos atuando
como voluntária na gestão de projetos e atividades do
Branch Sorocaba do PMI.
• Conhecimentos de gestão de projetos seguindo o guia
PMBoK/PMI e vivência em projetos ágeis.
• Atua como voluntária na coordenação do Branch
Sorocaba do PMI São Paulo.
• Gerente de Projetos em consultoria de planejamento
em Alphaville_
Voutecontarumahistória...
+ =
Programador + demanda, chefe com pressa = gambiarra, código ruim!
Parecebomacurtoprazo,mas...
Alongoprazooproblemavaisetornaralgomaior...
Exemplodepráticasruins...
Consequências...
• Novas implementações começam a ficar inviáveis;
• Maior custo/tempo de manutenção;
• Replanejar/remodelar o projeto todo - jogar fora e recomeçar do zero :(
Porqueescrevemoscódigosruins?
• Pressa;
• Pressão do cliente/gerente;
• Pelo cansaço de trabalhar no requisito/demanda;
• Excesso de tarefas;
• Aprenda a dizer não!
Afinal,queméoculpado?
Porquevocêestáaquihoje?
• É ou pretende ser programador(a)
• Deseja ser um profissional ainda melhor :)
• Deseja escrever um Código Limpo :D
25ª Semana da Tecnologia
da Fatec Sorocaba
A Arte do Código Limpo
Códigolimpo:
•Elegante, centralizado (um único objetivo);
•Coberto de testes;
•Refatorar* quando preciso;
•Fácil manutenção;
Códigolimpo:
"Qualquer um consegue escrever código que um computador
entende. Bons programadores escrevem código que humanos
endentem“ - Martin Fowler
Códigolimpo:
•Legível, de fácil entendimento/narração;
•Padrões definidos e nomenclatura que identifique o propósito;
•Modularizado;
Códigolimpo:
“Não é a linguagem que faz os programas parecerem simples, é
o programador.”
Códigolimpo:
•Um código limpo faz a linguagem parecer adequada para o
problema;
•Não há como criar um código sem lê-lo, portanto torná-lo de fácil
leitura facilita a escrita;
•Buscar o aperfeiçoamento contínuo do projeto :)
25ª Semana da Tecnologia
da Fatec Sorocaba
Nomessignificativos</>
•Use nomes que identifique o propósito;
•Clareza e simplicidade do código nos nomes de variáveis e
funções;
•Mudar variáveis para funções que descrevam seu
comportamento;
Nomessignificativos</>
•Evitar nomes abreviados, confusos ou semelhantes em funções e
variáveis;
•Evitar nomes que possam gerar ambiguidade no entendimento (Ex: l e
1);
•Nomes de variáveis não devem conter “variável”, “tabela” etc.
•Fazer distinção dos nomes de maneira que o leitor entenda as
diferenças;
Nomessignificativos</>
•Usar nomes pronunciáveis e pesquisáveis;
Nomessignificativos</>
•Nomes devem revelar a função/objetivo do código;
•Classes devem ser substantivos (Ex: Pessoa, Usuario, Funcionario)
•Métodos devem ser conter verbos e indicar uma ação:
• buscarRegistro()
• excluir()
• gerarBoleto()
Funções(){
•Dividir grandes blocos de código em funções menores - modularizar;
•A função no deve ser maior que a tela;
•Apenas uma linha dentro do if, else e while, geralmente chamando
outra função (com o descritivo da função);
•A função deve fazer apenas uma coisa;
•“Extrair” uma função de outra função;
Olhe o trecho de código em destaque...
Extraímos uma função daquele trecho, tornando o código legível!
Essa função deveria apenas fazer o upload de uma imagem, mas faz outras coisas!
O nome da função não condiz com o que ela faz.
Endentação(ou
identação)...
Visualmente melhor <3
Endentação(ouidentação)...
•Formatação: o que vale é a regra do time! {
}
Comentários*/
• Se o código for expressivo o suficiente, não precisa de comentários! Melhore
a narrativa do seu código ;)
• No geral, comentários servem para explicar um código ruim – o bom código é
auto documentado;
• Comentários vão ficando defasados ao longo da escrita do código;
• O ideal é focar esforços em tornar o código mais descritivo;
• Criar funções onde o nome da função diga a mesma coisa que o código diria;
Comentários*/
Comentários*/
•Quando houver comentários legais e sobre direitos autorais, é válido
fazer a referência a qual lei/licença a qual esse comentário se refere;
•Comentários informativos sobre retorno de objetos podem ser úteis –
mas só quando não houver outra alternativa;
•Usar comentários também quando desejar documentar uma decisão que
foi tomada no código (um retorno, uma prioridade etc);
Comentários*/
•Comentários para esclarecer parâmetros, valores, ou coisas inteligíveis.
Porém sempre há o risco desse comentário “esclarecedor” estar errado
ou defasado;
•Deixar comentários TODO, sobre a definição do que fazer em um
método, pode ser útil;
•Documentação de API’s públicas;
Objetoseestruturadedados;
Esse código facilita a adição de novas
funções sem precisar alterar a estrutura
de dados (classe e propriedades
existentes).
Aqui seria fácil adicionar um métodos
Perímetro a Classe Geometria.
Já esse código implementa funções de
uma classe abstrata Shape, e facilita
adicionar novas classes sem precisar
alterar as funções existentes.
Lei de demeter {
•Princípio do “mínimo conhecimento possível”;
•1 – Uma entidade deve conhecer o mínimo possível de outras entidades;
•2 – uma entidade só deve se relacionar com “amigos” (não deve falar
com “estranhos”);
•3 – Somente falar somente com “amigos próximos”;
Lei de demeter {
•Em resumo:
Um método M de uma classe C só conhece:
•Métodos de C
•Objetos criados por M
•Objetos passados como argumentos para M
•Objetos em variáveis de instâncias de C
Lei de demeter {
•Benefícios:
•Melhora a manutenção de código;
•Mais fácil de adaptar/expandir classes;
•Menos dependências;
Tratamento de erros!
•Exceções tratadas ao invés de códigos/strings de erros;
•Tratamento de exceções devem estar dentro das funções ou métodos;
•Não usar exceções genéricas: tratar as exceções para cada tipo de erro;
•Não retornar nulo nas exceções;
Dicas finais =)
•Melhoria contínua;
•Não deixe acumular problemas – ócio produtivo ;)
•Refatoração do código do amiguinho;
•Falar sobre código limpo é o primeiro passo ;)
Referência:
• The Clean Coder - Robert C.
Martin Programador desde 1970;
Fundador e Presidente Object
Mentor Inc. Livros:
• Designing Object-Oriented C++
Applications using the Booch Method.
1995.
• Agile Software Development:
Principles, Patterns and Practices.
2002.
• Clean Code: A Handbook of Agile
Software Craftsmanship.
25ª Semana da Tecnologia da
Fatec Sorocaba
<Juliana Fideles>
{ gerente de projetos • full stack developer }
www.linkedin.com/in/julianafideles

Mais conteúdo relacionado

Mais procurados

Princípios Básicos para Desenvolvedores
Princípios Básicos para DesenvolvedoresPrincípios Básicos para Desenvolvedores
Princípios Básicos para Desenvolvedores
guitoper
 
A importância da programação funcional no dia a-dia
A importância da programação funcional no dia a-diaA importância da programação funcional no dia a-dia
A importância da programação funcional no dia a-dia
Gabriel Schade Cardoso
 
Clean Code (Robert C. Martin)
Clean Code (Robert C. Martin)Clean Code (Robert C. Martin)
Clean Code (Robert C. Martin)
Yasser Veleda
 
Código limpo
Código limpoCódigo limpo
Código limpo
clauvane1708
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
Rogerio Fontes
 
Qualidade de Código
Qualidade de CódigoQualidade de Código
Qualidade de Código
Victor Queiroga
 
Aprendendo a programar - Programação Procedural vs OOP
Aprendendo a programar - Programação Procedural vs OOPAprendendo a programar - Programação Procedural vs OOP
Aprendendo a programar - Programação Procedural vs OOP
Leonardo Bastos
 
Lógica de programação, algoritmos e big data
Lógica de programação, algoritmos e big dataLógica de programação, algoritmos e big data
Lógica de programação, algoritmos e big data
Rodrigofn
 
Processo de Desenvolvimento de Software - Programação
Processo de Desenvolvimento de Software - ProgramaçãoProcesso de Desenvolvimento de Software - Programação
Processo de Desenvolvimento de Software - Programação
Natanael Simões
 
Introdução à programação funcional
Introdução à programação funcionalIntrodução à programação funcional
Introdução à programação funcional
Gabriel Schade Cardoso
 
Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)
Rodrigo Kono
 
Ruby
RubyRuby
Aula 04
Aula 04Aula 04
Aula 04
graconlima
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
Felipe Do Nascimento
 
Clean Code
Clean CodeClean Code
Clean Code
Bruno Lui
 
Codigo limpo
Codigo limpoCodigo limpo
Codigo limpo
diegomcunha
 
Clean code em C#
Clean code em C#Clean code em C#
Clean code em C#
Gustavo Araújo
 
Microsoft C#
Microsoft C#Microsoft C#
Microsoft C#
Lhaís Rodrigues
 
Paradigmas de programação
Paradigmas de programaçãoParadigmas de programação
Paradigmas de programação
Sérgio Souza Costa
 
Java 8 e lambdas (palestra Techday 2.0)
Java 8 e lambdas (palestra Techday 2.0)Java 8 e lambdas (palestra Techday 2.0)
Java 8 e lambdas (palestra Techday 2.0)
Douglas Frari
 

Mais procurados (20)

Princípios Básicos para Desenvolvedores
Princípios Básicos para DesenvolvedoresPrincípios Básicos para Desenvolvedores
Princípios Básicos para Desenvolvedores
 
A importância da programação funcional no dia a-dia
A importância da programação funcional no dia a-diaA importância da programação funcional no dia a-dia
A importância da programação funcional no dia a-dia
 
Clean Code (Robert C. Martin)
Clean Code (Robert C. Martin)Clean Code (Robert C. Martin)
Clean Code (Robert C. Martin)
 
Código limpo
Código limpoCódigo limpo
Código limpo
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
 
Qualidade de Código
Qualidade de CódigoQualidade de Código
Qualidade de Código
 
Aprendendo a programar - Programação Procedural vs OOP
Aprendendo a programar - Programação Procedural vs OOPAprendendo a programar - Programação Procedural vs OOP
Aprendendo a programar - Programação Procedural vs OOP
 
Lógica de programação, algoritmos e big data
Lógica de programação, algoritmos e big dataLógica de programação, algoritmos e big data
Lógica de programação, algoritmos e big data
 
Processo de Desenvolvimento de Software - Programação
Processo de Desenvolvimento de Software - ProgramaçãoProcesso de Desenvolvimento de Software - Programação
Processo de Desenvolvimento de Software - Programação
 
Introdução à programação funcional
Introdução à programação funcionalIntrodução à programação funcional
Introdução à programação funcional
 
Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)
 
Ruby
RubyRuby
Ruby
 
Aula 04
Aula 04Aula 04
Aula 04
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
 
Clean Code
Clean CodeClean Code
Clean Code
 
Codigo limpo
Codigo limpoCodigo limpo
Codigo limpo
 
Clean code em C#
Clean code em C#Clean code em C#
Clean code em C#
 
Microsoft C#
Microsoft C#Microsoft C#
Microsoft C#
 
Paradigmas de programação
Paradigmas de programaçãoParadigmas de programação
Paradigmas de programação
 
Java 8 e lambdas (palestra Techday 2.0)
Java 8 e lambdas (palestra Techday 2.0)Java 8 e lambdas (palestra Techday 2.0)
Java 8 e lambdas (palestra Techday 2.0)
 

Semelhante a A Arte do Código Limpo

Codigo limpo.pptx
Codigo limpo.pptxCodigo limpo.pptx
Análise de sistemas oo 1
Análise de sistemas oo   1Análise de sistemas oo   1
Análise de sistemas oo 1
Maurício Linhares
 
Clean code
Clean codeClean code
Clean code 101 do caos ao nirvana em poucos passos
Clean code 101  do caos ao nirvana em poucos passosClean code 101  do caos ao nirvana em poucos passos
Clean code 101 do caos ao nirvana em poucos passos
Gabrielly Gomes
 
Clean Code: Por um mundo com códigos melhores - SETI 2017
Clean Code: Por um mundo com códigos melhores - SETI 2017Clean Code: Por um mundo com códigos melhores - SETI 2017
Clean Code: Por um mundo com códigos melhores - SETI 2017
Thiago Barradas
 
O que é ser um bom programador?
O que é ser um bom programador?O que é ser um bom programador?
O que é ser um bom programador?
Lucas Boeing Scarduelli
 
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
Gilmar PSL
 
Projeto de API, por Gilmar P.S
Projeto de API, por Gilmar P.SProjeto de API, por Gilmar P.S
Projeto de API, por Gilmar P.S
Thoughtworks
 
Clean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimentoClean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimento
Paulo Henrique da Silva
 
Code Smells
Code SmellsCode Smells
Code Smells
Alan Willms
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
Rafael Paz
 
#DNAD15 - Diminuindo sofrimento com código legado de linguagens não mainstreams
#DNAD15  - Diminuindo sofrimento com código legado de linguagens não mainstreams#DNAD15  - Diminuindo sofrimento com código legado de linguagens não mainstreams
#DNAD15 - Diminuindo sofrimento com código legado de linguagens não mainstreams
Jacqueline Abreu
 
Programe a eficácia do seu código
Programe a eficácia do seu códigoPrograme a eficácia do seu código
Programe a eficácia do seu código
Ana Claudia Nogueira
 
PHPZEIRO: Adote um framework
PHPZEIRO: Adote um frameworkPHPZEIRO: Adote um framework
PHPZEIRO: Adote um framework
Leonardo "Hackin" Freire
 
Clean Code na prática
Clean Code na práticaClean Code na prática
Clean Code na prática
Evelise Vazquez
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
elliando dias
 
Seja um júnior não seja um sobrinho
Seja um júnior não seja um sobrinhoSeja um júnior não seja um sobrinho
Seja um júnior não seja um sobrinho
Alexandre Andrade
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
gustavoferrazfontes
 
Boas praticas em_desenvolvimento_de_software
Boas praticas em_desenvolvimento_de_softwareBoas praticas em_desenvolvimento_de_software
Boas praticas em_desenvolvimento_de_software
ivanassisleal
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao Sênior
Marcos Pereira
 

Semelhante a A Arte do Código Limpo (20)

Codigo limpo.pptx
Codigo limpo.pptxCodigo limpo.pptx
Codigo limpo.pptx
 
Análise de sistemas oo 1
Análise de sistemas oo   1Análise de sistemas oo   1
Análise de sistemas oo 1
 
Clean code
Clean codeClean code
Clean code
 
Clean code 101 do caos ao nirvana em poucos passos
Clean code 101  do caos ao nirvana em poucos passosClean code 101  do caos ao nirvana em poucos passos
Clean code 101 do caos ao nirvana em poucos passos
 
Clean Code: Por um mundo com códigos melhores - SETI 2017
Clean Code: Por um mundo com códigos melhores - SETI 2017Clean Code: Por um mundo com códigos melhores - SETI 2017
Clean Code: Por um mundo com códigos melhores - SETI 2017
 
O que é ser um bom programador?
O que é ser um bom programador?O que é ser um bom programador?
O que é ser um bom programador?
 
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
Projeto de API - TDC 2014 - Floripa - Trilha Arquitetura - 18/05/2014
 
Projeto de API, por Gilmar P.S
Projeto de API, por Gilmar P.SProjeto de API, por Gilmar P.S
Projeto de API, por Gilmar P.S
 
Clean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimentoClean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimento
 
Code Smells
Code SmellsCode Smells
Code Smells
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
 
#DNAD15 - Diminuindo sofrimento com código legado de linguagens não mainstreams
#DNAD15  - Diminuindo sofrimento com código legado de linguagens não mainstreams#DNAD15  - Diminuindo sofrimento com código legado de linguagens não mainstreams
#DNAD15 - Diminuindo sofrimento com código legado de linguagens não mainstreams
 
Programe a eficácia do seu código
Programe a eficácia do seu códigoPrograme a eficácia do seu código
Programe a eficácia do seu código
 
PHPZEIRO: Adote um framework
PHPZEIRO: Adote um frameworkPHPZEIRO: Adote um framework
PHPZEIRO: Adote um framework
 
Clean Code na prática
Clean Code na práticaClean Code na prática
Clean Code na prática
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
 
Seja um júnior não seja um sobrinho
Seja um júnior não seja um sobrinhoSeja um júnior não seja um sobrinho
Seja um júnior não seja um sobrinho
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Boas praticas em_desenvolvimento_de_software
Boas praticas em_desenvolvimento_de_softwareBoas praticas em_desenvolvimento_de_software
Boas praticas em_desenvolvimento_de_software
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao Sênior
 

A Arte do Código Limpo

  • 1. 25ª Semana da Tecnologia da Fatec Sorocaba <Juliana Fideles> { gerente de projetos • full stack developer }
  • 2. Quemsoueu? • Formada em Análise e Desenvolvimento de Sistemas pela Fatec Sorocaba e pós-graduada em gerenciamento de projetos pelo Senac Sorocaba. • Possui mais de 6 anos de experiência na área de tecnologia da informação. Mais de 2 anos atuando como voluntária na gestão de projetos e atividades do Branch Sorocaba do PMI. • Conhecimentos de gestão de projetos seguindo o guia PMBoK/PMI e vivência em projetos ágeis. • Atua como voluntária na coordenação do Branch Sorocaba do PMI São Paulo. • Gerente de Projetos em consultoria de planejamento em Alphaville_
  • 3. Voutecontarumahistória... + = Programador + demanda, chefe com pressa = gambiarra, código ruim!
  • 6. Consequências... • Novas implementações começam a ficar inviáveis; • Maior custo/tempo de manutenção; • Replanejar/remodelar o projeto todo - jogar fora e recomeçar do zero :(
  • 7. Porqueescrevemoscódigosruins? • Pressa; • Pressão do cliente/gerente; • Pelo cansaço de trabalhar no requisito/demanda; • Excesso de tarefas; • Aprenda a dizer não!
  • 9. Porquevocêestáaquihoje? • É ou pretende ser programador(a) • Deseja ser um profissional ainda melhor :) • Deseja escrever um Código Limpo :D
  • 10. 25ª Semana da Tecnologia da Fatec Sorocaba
  • 12. Códigolimpo: •Elegante, centralizado (um único objetivo); •Coberto de testes; •Refatorar* quando preciso; •Fácil manutenção;
  • 13. Códigolimpo: "Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos endentem“ - Martin Fowler
  • 14. Códigolimpo: •Legível, de fácil entendimento/narração; •Padrões definidos e nomenclatura que identifique o propósito; •Modularizado;
  • 15. Códigolimpo: “Não é a linguagem que faz os programas parecerem simples, é o programador.”
  • 16. Códigolimpo: •Um código limpo faz a linguagem parecer adequada para o problema; •Não há como criar um código sem lê-lo, portanto torná-lo de fácil leitura facilita a escrita; •Buscar o aperfeiçoamento contínuo do projeto :)
  • 17. 25ª Semana da Tecnologia da Fatec Sorocaba
  • 18. Nomessignificativos</> •Use nomes que identifique o propósito; •Clareza e simplicidade do código nos nomes de variáveis e funções; •Mudar variáveis para funções que descrevam seu comportamento;
  • 19. Nomessignificativos</> •Evitar nomes abreviados, confusos ou semelhantes em funções e variáveis; •Evitar nomes que possam gerar ambiguidade no entendimento (Ex: l e 1); •Nomes de variáveis não devem conter “variável”, “tabela” etc. •Fazer distinção dos nomes de maneira que o leitor entenda as diferenças;
  • 21. Nomessignificativos</> •Nomes devem revelar a função/objetivo do código; •Classes devem ser substantivos (Ex: Pessoa, Usuario, Funcionario) •Métodos devem ser conter verbos e indicar uma ação: • buscarRegistro() • excluir() • gerarBoleto()
  • 22. Funções(){ •Dividir grandes blocos de código em funções menores - modularizar; •A função no deve ser maior que a tela; •Apenas uma linha dentro do if, else e while, geralmente chamando outra função (com o descritivo da função); •A função deve fazer apenas uma coisa; •“Extrair” uma função de outra função;
  • 23. Olhe o trecho de código em destaque...
  • 24. Extraímos uma função daquele trecho, tornando o código legível!
  • 25. Essa função deveria apenas fazer o upload de uma imagem, mas faz outras coisas! O nome da função não condiz com o que ela faz.
  • 29. Comentários*/ • Se o código for expressivo o suficiente, não precisa de comentários! Melhore a narrativa do seu código ;) • No geral, comentários servem para explicar um código ruim – o bom código é auto documentado; • Comentários vão ficando defasados ao longo da escrita do código; • O ideal é focar esforços em tornar o código mais descritivo; • Criar funções onde o nome da função diga a mesma coisa que o código diria;
  • 31. Comentários*/ •Quando houver comentários legais e sobre direitos autorais, é válido fazer a referência a qual lei/licença a qual esse comentário se refere; •Comentários informativos sobre retorno de objetos podem ser úteis – mas só quando não houver outra alternativa; •Usar comentários também quando desejar documentar uma decisão que foi tomada no código (um retorno, uma prioridade etc);
  • 32. Comentários*/ •Comentários para esclarecer parâmetros, valores, ou coisas inteligíveis. Porém sempre há o risco desse comentário “esclarecedor” estar errado ou defasado; •Deixar comentários TODO, sobre a definição do que fazer em um método, pode ser útil; •Documentação de API’s públicas;
  • 34. Esse código facilita a adição de novas funções sem precisar alterar a estrutura de dados (classe e propriedades existentes). Aqui seria fácil adicionar um métodos Perímetro a Classe Geometria.
  • 35. Já esse código implementa funções de uma classe abstrata Shape, e facilita adicionar novas classes sem precisar alterar as funções existentes.
  • 36. Lei de demeter { •Princípio do “mínimo conhecimento possível”; •1 – Uma entidade deve conhecer o mínimo possível de outras entidades; •2 – uma entidade só deve se relacionar com “amigos” (não deve falar com “estranhos”); •3 – Somente falar somente com “amigos próximos”;
  • 37. Lei de demeter { •Em resumo: Um método M de uma classe C só conhece: •Métodos de C •Objetos criados por M •Objetos passados como argumentos para M •Objetos em variáveis de instâncias de C
  • 38. Lei de demeter { •Benefícios: •Melhora a manutenção de código; •Mais fácil de adaptar/expandir classes; •Menos dependências;
  • 39. Tratamento de erros! •Exceções tratadas ao invés de códigos/strings de erros; •Tratamento de exceções devem estar dentro das funções ou métodos; •Não usar exceções genéricas: tratar as exceções para cada tipo de erro; •Não retornar nulo nas exceções;
  • 40. Dicas finais =) •Melhoria contínua; •Não deixe acumular problemas – ócio produtivo ;) •Refatoração do código do amiguinho; •Falar sobre código limpo é o primeiro passo ;)
  • 41. Referência: • The Clean Coder - Robert C. Martin Programador desde 1970; Fundador e Presidente Object Mentor Inc. Livros: • Designing Object-Oriented C++ Applications using the Booch Method. 1995. • Agile Software Development: Principles, Patterns and Practices. 2002. • Clean Code: A Handbook of Agile Software Craftsmanship.
  • 42. 25ª Semana da Tecnologia da Fatec Sorocaba <Juliana Fideles> { gerente de projetos • full stack developer } www.linkedin.com/in/julianafideles