Les odeurs de code sont un classique.

Ça sent mauvais parce qu'il y a probablement de nombreux cas où il pourrait être modifié ou amélioré.

La plupart de ces odeurs ne sont que des indices de quelque chose qui pourrait ne pas fonctionner. Par conséquent, ils ne sont pas tenus d'être corrigés en soi… (Vous devriez cependant y jeter un coup d'œil.)

Odeurs de code précédentes

Vous pouvez trouver toutes les odeurs de code précédentes (Partie I - XXIX) ici

Nous allons continuer...

Code Odeur 146 - Getter Commentaires

Les commentaires sont un code Odeur. Les getters sont une autre odeur de code. Devine quoi?

TL;DR : N'utilisez pas de getters. Ne commentez pas les getters

Problèmes

• Agresseurs de commentaires
• Lisibilité
• Getters

Solutions

1. Supprimer les commentaires getter
2. Supprimer les getters

Le contexte

Il y a quelques décennies, nous avions l'habitude de commenter chaque méthode. Même les plus anodins.

Le commentaire doit décrire uniquement une décision de conception critique.

Exemple de code

Faux

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private price; function getPrice() public view returns(int) { /* returns the Price */ return price; } }

Droite

 pragma solidity >=0.5.0 <0.9.0; contract Property { int private _price; function price() public view returns(int) { return _price; } }

Détection

• [x] Semi-automatique

Nous pouvons détecter si une méthode est un getter et a un commentaire.

Des exceptions

La fonction a besoin d'un commentaire, qui est accidentellement un getter et le commentaire est lié à une décision de conception

Mots clés

• commentaires

Conclusion

Ne commentez pas les getters.

Ils n'ajoutent aucune valeur réelle et gonflent votre code.

Rapports

Code Smell 05 - Agresseurs de commentaires

Code Odeur 68 - Getters

Code Smell 01 - Modèles anémiques

Crédits

Photo de Reimond de Zuñiga sur Unsplash

Le code doit être remarquablement expressif pour éviter la plupart des commentaires. Il y aura quelques exceptions, mais nous devrions considérer les commentaires comme un "défaut d'expression" jusqu'à preuve du contraire.

Robert Martin

Excellentes citations de génie logiciel

Code Smell 147 - Trop de méthodes

Les classes Util sont idéales pour rassembler le protocole.

TL; DR : N'ajoutez pas de protocole accidentel à vos cours

Problèmes

• Lisibilité
• Violation de responsabilité unique
• Mauvaise cohésion
• Couplage élevé
• Faible réutilisabilité

Solutions

1. Casse ta classe
2. Extraire la classe

Refactorisations

Refactoring 007 - Classe d'extraction

Le contexte

Nous avons tendance à mettre un protocole dans la première classe que nous trouvons.

Ce n'est pas un problème.

Nous avons juste besoin de refactoriser.

Exemple de code

Faux

 public class MyHelperClass { public void print() { } public void format() { } // ... many methods more // ... even more methods public void persist() { } public void solveFermiParadox() { } }

Droite

 public class Printer { public void print() { } } public class DateToStringFormatter { public void format() { } } public class Database { public void persist() { } } public class RadioTelescope { public void solveFermiParadox() { } }

Détection

• [x] Automatique

La plupart des linters comptent les méthodes et nous avertissent.

Rapports

Code Odeur 124 - Changement divergent

Code Smell 143 - Amas de données

Code Smell 94 - Trop d'importations

Code Odeur 22 - Aides

Code Smell 34 - Trop d'attributs

Plus d'informations

Gourou de la refactorisation

Mots clés

• Cohésion
• Ballonnements

Conclusion

Le fractionnement des classes et du protocole est une bonne pratique pour privilégier les objets petits et réutilisables.

Crédits

Photo de Marcin Simonides sur Unsplash

Il n'y a pas de code si gros, tordu ou complexe que la maintenance ne puisse pas l'aggraver.

Gérald M. Weinberg

Code Odeur 148 - ToDos

Nous achetons des dettes pour notre futur. C'est le temps de la récupération.

TL;DR : Ne laissez pas de TODO dans votre code. Répare les!

Problèmes

• Dette technique
• Lisibilité
• Manque de confiance

Solutions

1. Corrigez vos TODO

Le contexte

Nous rencontrons des TODO dans notre code. Nous les comptons.

Nous l'abordons rarement.

Nous avons commencé à devoir la dette technique.

Ensuite, nous payons la dette + les intérêts.

Quelques mois après, nous payons plus d'intérêts que la dette initiale.

Exemple de code

Faux

 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 } }

Droite

 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; } }

Détection

• [x] Automatique

Nous pouvons compter les TODO.

Mots clés

• Dette technique

Conclusion

Nous pouvons compter les TODO.

La plupart des linters le font.

Nous avons besoin de la politique pour les réduire.

Si nous utilisons TDD, nous écrivons immédiatement le code manquant.

Dans ce contexte, les TODO ne sont valables que lors d'un développement Depth First pour se souvenir des chemins ouverts à visiter.

Plus d'informations

• Faut-il mettre des ToDos ?
• Théorie des fenêtres cassées

Crédits

Photo par Eden Constantino sur Unsplash

Après avoir terminé les premiers 90 % d'un projet, vous devez terminer les 90 % restants.

Michel Abrash

Code Smell 149 - Enchaînement optionnel

Notre code est plus robuste et lisible. Mais nous cachons NULL sous le tapis.

TL ; DR : évitez les valeurs nulles et indéfinies. Si vous les évitez, vous n'aurez jamais besoin d'options.

Problèmes

• Nuls
• SI polluant

Solutions

1. Supprimer les valeurs nulles
2. Traiter avec indéfini

Le contexte

Le chaînage facultatif, les options, la coalescence et de nombreuses autres solutions nous aident à gérer les tristement célèbres valeurs nulles.

Il n'est pas nécessaire de les utiliser une fois que notre code est mature, robuste et sans null.

Exemple de code

Faux

 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

Droite

 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

Détection

• [x] Automatique

Il s'agit d'une fonctionnalité linguistique .

Nous pouvons le détecter et le supprimer.

Mots clés

• Nul

Conclusion

De nombreux développeurs se sentent en sécurité en polluant le code avec des transactions nulles.

En fait, c'est plus sûr que de ne pas traiter du tout les NULL.

Les valeurs nulles , le vrai et le faux sont aussi des odeurs de code.

Nous devons viser plus haut et créer un code plus propre.

Le bon : supprimez tous les nulls de votre code.

Le mauvais : utilisez le chaînage optionnel.

Le laid : ne pas traiter du tout les nulls.

Rapports

Code Smell 145 - Hack de court-circuit

Code Odeur 12 - Nulle

Code Smell 69 - Big Bang (JavaScript Ridicule Castings)

Plus d'informations

• Référence de chaînage facultative

Null : l'erreur d'un milliard de dollars

Comment se débarrasser des IF ennuyeux pour toujours

QUOI ?

Crédits

Photo par engin akyurt sur Unsplash

Celui qui se bat avec des monstres pourrait prendre garde de ne pas devenir un monstre. Et si tu regardes longtemps dans un abîme, l'abîme te regarde aussi.

Nietzsche

Code Smell 150 - Comparaison égale

Chaque développeur compare les attributs de manière égale. Ils se trompent.

TL;DR : N'exportez pas et ne comparez pas, comparez simplement.

Problèmes

• Rupture d'encapsulation
• Duplication de code
• Violation de la dissimulation d'informations
• Violation de l'anthropomorphisme

Solutions

1. Masquer la comparaison en une seule méthode

Le contexte

La comparaison d'attributs est fortement utilisée dans notre code.

Nous devons nous concentrer sur le comportement et les responsabilités.

C'est la responsabilité d'un objet de se comparer à d'autres objets. Pas le nôtre.

Les optimiseurs prématurés nous diront que c'est moins performant.

Nous devrions leur demander des preuves réelles et opposer la solution la plus maintenable.

Exemple de code

Faux

 if (address.street == 'Broad Street') { if (location.street == 'Bourbon St') { // 15000 usages in a big system // Comparisons are case sensitive

Droite

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

Détection

• [x] Semi-automatique

Nous pouvons détecter les comparaisons d'attributs à l'aide d'arbres de syntaxe.

Il peut y avoir de bonnes utilisations pour les types primitifs comme pour de nombreuses autres odeurs.

Mots clés

• Encapsulation

Conclusion

Nous devons regrouper les responsabilités en un seul endroit.

La comparaison en est une.

Si certaines de nos règles commerciales changent, nous devons changer un seul point .

Rapports

Code Smell 63 - Envie de fonctionnalité

Code Smell 101 - Comparaison avec les booléens

Code Smell 122 - Obsession primitive

Crédits

Photo de Piret Ilver sur Unsplash

Le comportement est la chose la plus importante à propos des logiciels. C'est ce dont dépendent les utilisateurs. Les utilisateurs aiment que nous ajoutions un comportement (à condition que ce soit ce qu'ils voulaient vraiment), mais si nous modifions ou supprimons un comportement dont ils dépendent (introduisons des bogues), ils cessent de nous faire confiance.

Michel Plumes

Article suivant : 5 autres odeurs de code.