Code Smells são um clássico.  Cheira porque provavelmente há muitos casos em que poderia ser editado ou melhorado.  A maioria desses cheiros são apenas indícios de algo que pode estar errado. Portanto, eles não precisam ser consertados per se... (Você deve dar uma olhada nisso, no entanto.)   Código anterior cheira  Você pode encontrar todos os cheiros de código anteriores (Parte i - XXIX)  aqui  Vamos continuar...  Code Smell 146 - Comentários do Getter    Os comentários são um cheiro de código. Getters são outro cheiro de código. Adivinha?  TL;DR: Não use getters. Não comente getters  problemas  Abusadores de comentários  Legibilidade  Getters  Soluções  Remover comentários do getter  Remover getters  Contexto  Algumas décadas atrás, costumávamos comentar sobre todos os métodos. Mesmo triviais.  O comentário deve descrever apenas uma decisão crítica de projeto.  Código de amostra  Errado   pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } }  Direita   pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } }  Detecção    Semiautomático [x]  Podemos detectar se um método é um getter e tem um comentário.  Exceções  A função precisa de um comentário, que é acidentalmente um getter e o comentário está relacionado a uma decisão de design  Tag  Comentários  Conclusão  Não comente getters.  Eles não agregam valor real e incham seu código.  Relações   Code Smell 05 - Abusadores de comentários   Code Smell 68 - Getters   Cheiro de Código 01 - Modelos Anêmicos  Créditos   Foto de Reimond de Zuñiga no Unsplash  O código deve ser notavelmente expressivo para evitar a maioria dos comentários. Haverá algumas exceções, mas devemos ver os comentários como uma 'falha de expressão' até que se prove que estão errados.   Robert Martin   Grandes Citações de Engenharia de Software  Cheiro de Código 147 - Muitos Métodos    Classes utilitárias são ótimas para reunir protocolo.  TL;DR: Não adicione protocolo acidental às suas aulas  problemas  Legibilidade  Violação de responsabilidade única  Coesão Ruim  Acoplamento alto  Baixa reutilização  Soluções  Quebre sua classe   Extrair classe  Refatorações   Refatoração 007 - Extrair classe  Contexto  Costumamos colocar um protocolo na primeira aula que encontramos.  Isso não é um problema.  Só precisamos refatorar.  Código de amostra  Errado   public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } }  Direita   public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } }  Detecção    Automático [x]  A maioria dos linters contam métodos e nos avisam.  Relações   Cheiro de Código 124 - Mudança Divergente   Cheiro de Código 143 - Aglomerados de Dados   Code Smell 94 - Muitas importações   Code Smell 22 - Ajudantes   Cheiro de Código 34 - Muitos Atributos  Mais informações   Guru de refatoração  Tag  Coesão  Bloaters  Conclusão  Dividir classes e protocolo é uma boa prática para favorecer objetos pequenos e reutilizáveis.  Créditos   Foto de   no  Marcin Simonides Unsplash  Não há código tão grande, distorcido ou complexo que a manutenção não possa piorar.  Gerald M. Weinberg  Code Smell 148 - ToDos    Compramos dívidas para o nosso eu futuro. É hora do retorno.  TL;DR: Não deixe TODOs em seu código. Consertá-los!  problemas  Dívida Técnica  Legibilidade  Falta de confiança  Soluções  Corrija seus TODOs  Contexto  Encontramos TODOs em nosso código. Nós os contamos.  Raramente abordamos isso.  Começamos com a dívida técnica.  Depois pagamos a dívida + os juros.  Alguns meses depois, pagamos mais juros do que a dívida original.  Código de amostra  Errado   public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { // TODO: Implement close door and cover it } }  Direita   public class Door { private Boolean isOpened; public Door(boolean isOpened) { this.isOpened = isOpened; } public void openDoor() { this.isOpened = true; } public void closeDoor() { this.isOpened = false; } }  Detecção    Automático [x]  Podemos contar TODOs.  Tag  Dívida Técnica  Conclusão  Podemos contar TODOs.  A maioria dos linters faz isso.  Precisamos de uma política para reduzi-los.  Se estivermos usando TDD, escrevemos o código que falta imediatamente.  Nesse contexto, os TODOs são válidos apenas ao fazer o desenvolvimento do Depth First para lembrar os caminhos abertos a serem visitados.  Mais informações   Você deve colocar ToDos?   Teoria das janelas quebradas  Créditos   Foto de   no  Eden Constantino Unsplash  Depois de terminar os primeiros 90% de um projeto, você deve terminar os outros 90%.   Michael Abrash  Code Smell 149 - Encadeamento opcional    Nosso código é mais robusto e legível. Mas escondemos NULL debaixo do tapete.  TL;DR: Evite nulos e indefinidos. Se você evitá-los, nunca precisará dos Opcionais.  problemas  Nulos   SE Poluir  Soluções  Remover nulos  Lidar com indefinido  Contexto    opcional, opcionais, coalescência e muitas outras soluções nos ajudam a lidar com os infames nulos. Encadeamento  Não há necessidade de usá-los quando nosso código estiver maduro, robusto e sem nulos.  Código de amostra  Errado   const user = { name: 'Hacker' }; if (user?.credentials?.notExpired) { user.login(); } user.functionDefinedOrNot?.(); // Seems compact but it is hacky and has lots // of potential NULLs and Undefined  Direita   function login() {} const user = { name: 'Hacker', credentials: { expired: false } }; if (!user.credentials.expired) { login(); } // Also compact // User is a real user or a polymorphic NullUser // Credentials are always defined. // Can be an instance of InvalidCredentials // Assuming we eliminated nulls from our code if (user.functionDefinedOrNot !== undefined) { functionDefinedOrNot(); } // This is also wrong. // Explicit undefined checks are yet another code smell  Detecção    Automático [x]  Este é um   . recurso de idioma  Podemos detectá-lo e removê-lo.  Tag  Nulo  Conclusão  Muitos desenvolvedores se sentem seguros em poluir o código com tratamento nulo.  Na verdade, isso é mais seguro do que não tratar NULLs.    , Truthy e Falsy também são code smells. Nullish Values  Precisamos mirar mais alto e criar um código mais limpo.    : remova todos os nulos do seu código. O bom    : use encadeamento opcional. O ruim    : não tratar nulos. O feio  Relações   Code Smell 145 - Hack de curto-circuito   Cheiro de Código 12 - Nulo   Code Smell 69 - Big Bang (JavaScript Ridiculous Castings)  Mais informações   Referência de encadeamento opcional   Nulo: O erro de um bilhão de dólares   Como se livrar de IFs irritantes para sempre   O QUE?  Créditos   Foto por   no  engin akyurt Unsplash  Aquele que luta com monstros deve tomar cuidado para não se tornar um monstro. E se você olhar por muito tempo para um abismo, o abismo também olha para você.   nietzsche  Code Smell 150 - Comparação Igual    Todo desenvolvedor compara os atributos igualmente. Eles estão enganados.  TL;DR: Não exporte e compare, apenas compare.  problemas  Quebra de encapsulamento  Duplicação de código  Violação de ocultação de informações  violação  de antropomorfismo  Soluções  Ocultar a comparação em um único método  Contexto  A comparação de atributos é muito usada em nosso código.  Precisamos nos concentrar no comportamento e nas responsabilidades.  É responsabilidade de um objeto comparar com outros objetos. Não o nosso.  Otimizadores prematuros nos dirão que isso tem menos desempenho.  Devemos pedir-lhes evidências reais e comparar a solução mais sustentável.  Código de amostra  Errado   if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive  Direita   if (address.isAtStreet('Broad Street') { } // ... if (location.isAtStreet('Bourbon St') { } // 15000 usages in a big system function isAtStreet(street) { // We can change Comparisons to // case sensitive in just one place. }  Detecção    Semiautomático [x]  Podemos detectar comparações de atributos usando árvores de sintaxe.  Pode haver bons usos para tipos primitivos, assim como muitos outros cheiros.  Tag  Encapsulamento  Conclusão  Precisamos colocar as responsabilidades em um único lugar.  Comparar é uma delas.  Se algumas de nossas regras de negócios mudarem, precisamos mudar um   . único ponto  Relações   Code Smell 63 - Inveja de recursos   Code Smell 101 - Comparação com Booleanos   Code Smell 122 - Obsessão Primitiva  Créditos   Foto de   no  Piret Ilver Unsplash  O comportamento é a coisa mais importante sobre o software. É disso que os usuários dependem. Os usuários gostam quando adicionamos um comportamento (desde que seja o que eles realmente desejam), mas se mudarmos ou removermos o comportamento do qual eles dependem (introduzirmos bugs), eles param de confiar em nós.   Michael Feathers  Próximo artigo: 5 mais cheiros de código.

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

2020 - Hacker Noon Contributor of the Year in REFACTORING

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Github

2022 - HackerNoon Contributor of the Year - Machine Learning

2022 - HackerNoon Contributor of the Year - Quality Assurance

2022 - HackerNoon Contributor of the Year - Refactoring

2022 - HackerNoon Contributor of the Year - Software Architecture

2022 - the Greatest Storyteller

Buy My Book

Share your ideas with me!

Read My Stories

Buy Me a Coffee

Software Engineer and Book Author

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Como encontrar as partes fedorentas do seu código [Parte XXX]

Como encontrar as partes fedorentas do seu código [Parte XXX]

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Modelo Bitcoin UTXO, alimentando um ecossistema único

Uma breve introdução à teoria do cérebro de Boltzmann

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Modelo Bitcoin UTXO, alimentando um ecossistema único

Uma breve introdução à teoria do cérebro de Boltzmann

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps