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

1. Remover comentários do getter
2. 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

• [x] Semiautomático

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

1. Quebre sua classe
2. 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

• [x] Automático

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 Marcin Simonides no 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

1. 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

• [x] Automático

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 Eden Constantino no 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

1. Remover nulos
2. Lidar com indefinido

Contexto

Encadeamento opcional, opcionais, coalescência e muitas outras soluções nos ajudam a lidar com os infames nulos.

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

• [x] Automático

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.

Nullish Values , Truthy e Falsy também são code smells.

Precisamos mirar mais alto e criar um código mais limpo.

O bom : remova todos os nulos do seu código.

O ruim : use encadeamento opcional.

O feio : não tratar nulos.

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 engin akyurt no 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

1. 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

• [x] Semiautomático

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 Piret Ilver no 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.