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  Supprimer les commentaires getter  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    Semi-automatique [x]  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  Casse ta classe   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    Automatique [x]  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   sur  Marcin Simonides 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  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    Automatique [x]  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   sur  Eden Constantino 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  Supprimer les valeurs nulles  Traiter avec indéfini  Le contexte    facultatif, les options, la coalescence et de nombreuses autres solutions nous aident à gérer les tristement célèbres valeurs nulles. Le chaînage  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    Automatique [x]  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.    , le vrai et le faux sont aussi des odeurs de code. Les valeurs nulles  Nous devons viser plus haut et créer un code plus propre.    : supprimez tous les nulls de votre code. Le bon    : utilisez le chaînage optionnel. Le mauvais    : ne pas traiter du tout les nulls. Le laid  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   sur  engin akyurt 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  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    Semi-automatique [x]  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   sur  Piret Ilver 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.

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

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Comment trouver les parties puantes de votre code [Partie XXX]

Comment trouver les parties puantes de votre code [Partie XXX]

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps