Votre code peut sentir! Comment le réparer

UNE odeur de code est un bloc de code ou un modèle de codage général qui semble indiquer un problème plus grave dans la structure et la conception générales d'un code.

Pensez à une odeur de code comme à tout signe suggérant qu'une section de code devrait être refactorisée. Ce n'est pas que le code soit bogué ou non fonctionnel - souvent, le code malodorant fonctionne très bien - mais le code malodorant est souvent difficile à maintenir et à étendre, ce qui peut entraîner des problèmes techniques (en particulier pour les grands projets).

Dans cet article, nous soulignerons 10 des odeurs de code les plus courantes, ce qu’il faut rechercher et comment les désodoriser. Si vous êtes un nouveau programmeur Comment apprendre à programmer sans stresser Comment apprendre à programmer sans stressé Peut-être avez-vous décidé de vous lancer dans la programmation, que ce soit pour une carrière ou comme un loisir. Génial! Mais peut-être que vous commencez à vous sentir dépassé. Pas si bien. Voici de l'aide pour faciliter votre voyage. En savoir plus, évitez ces erreurs et votre code sera sensiblement meilleur!

1. Couplage serré

Le problème
Le couplage étroit se produit lorsque deux objets sont tellement dépendants des données et / ou des fonctions de l'autre que la modification de l'un nécessite la modification de l'autre. Lorsque deux objets sont trop étroitement liés, apporter des modifications au code peut s'avérer cauchemardesque et il est plus probable que vous introduisiez des bogues à chaque modification..

Par exemple:

class Worker Vélo = nouveau vélo (); public void commute () bike.drive (); 

Dans ce cas, Worker et Bike sont étroitement couplés. Et si un jour vous vouliez conduire une voiture au lieu d'un vélo pour votre trajet? Vous devez accéder à la classe Worker et remplacer tout le code associé à Bike par le code associé à la voiture. C'est désordonné et sujet aux erreurs.

La solution
Vous pouvez desserrer le couplage en ajoutant une couche d'abstraction. Dans ce cas, la classe des travailleurs ne veut pas seulement conduire des vélos, mais aussi des voitures et peut-être des camions, voire des scooters. Ce sont tous des véhicules, n'est-ce pas? Créez donc une interface véhicule, qui vous permettra d’insérer et de remplacer différents types de véhicules à votre guise:

classe travailleur véhicule véhicule; changement de vide publicVéhicule (véhicule v) véhicule = v;  public void commute () vehicle.drive ();  interface Vehicle void drive ();  la classe vélo implémente véhicule public void drive ()  la classe voiture implémente véhicule public void drive () 

2. Objets de Dieu

Le problème
Un objet divin est une classe / un module massif contenant trop de variables et de fonctions. Il “en sait trop” et “fait trop,” ce qui est problématique pour deux raisons. Premièrement, les autres classes / modules deviennent trop dépendants de celle-ci pour les données (couplage étroit). Deuxièmement, la structure générale du programme devient boueuse alors que tout est entassé au même endroit..

La solution
Prenez un objet Dieu, séparez ses données et ses fonctions en fonction des problèmes à résoudre, puis transformez ces groupements en objets. Si vous avez un objet de Dieu, il peut être préférable de composer de nombreux objets plus petits..

Par exemple, supposons que vous ayez une classe d'utilisateurs monstrueuse:

class User public String nom d'utilisateur; mot de passe de chaîne publique; adresse de chaîne publique; chaîne publique zipcode; public int age;… public String getUsername () return username;  public void setUsername (String u) username = u; 

Vous pouvez le convertir en une composition de ce qui suit:

class User Identifiants d'identité; Profil de profil;… class Credentials public String username; public String password;… public String getUsername () return username;  public void setUsername (String u) username = u; 

La prochaine fois que vous devrez modifier les procédures de connexion, vous n'aurez pas à parcourir une classe d'utilisateurs volumineuse, car la classe d'informations d'identification est plus facile à gérer.!

3. Fonctions longues

Le problème
Une fonction longue correspond exactement à ce que cela ressemble: une fonction qui est devenue trop longue. Bien qu'il n'y ait pas de nombre spécifique pour combien de lignes de code est “trop long” pour une fonction, c'est une de ces choses où vous le savez quand vous le voyez. C'est à peu près une version plus étroite du problème de l'objet divin - une longue fonction a trop de responsabilités.

La solution
Les fonctions longues doivent être divisées en plusieurs sous-fonctions, chaque sous-fonction étant conçue pour traiter une tâche ou un problème unique. Idéalement, la fonction longue originale deviendra une liste d'appels de sous-fonctions, ce qui rend le code plus propre et plus facile à lire..

4. Paramètres excessifs

Le problème
Une fonction (ou un constructeur de classe) qui nécessite trop de paramètres pose problème pour deux raisons. Premièrement, cela rend le code moins lisible et le rend plus difficile à tester. Mais deuxièmement, et plus important encore, cela peut indiquer que le but de la fonction est trop ambigu et tente de gérer trop de responsabilités.

La solution
Tandis que “trop” est subjectif pour une liste de paramètres, nous vous recommandons de vous méfier de toute fonction ayant plus de 3 paramètres. Bien sûr, il est parfois utile d’avoir une seule fonction avec 5 voire 6 paramètres, mais seulement s’il ya une très bonne raison de le faire..

La plupart du temps, il n'y en a pas et le code serait mieux de diviser cette fonction en deux ou plusieurs fonctions différentes. Contrairement à la “Longues fonctions” odeur de code, celle-ci ne peut pas être résolue simplement en remplaçant le code par des sous-fonctions - la fonction elle-même doit être divisée et divisée en fonctions distinctes couvrant des responsabilités distinctes.

5. Identifiants mal nommés

Le problème
Noms de variables à une ou deux lettres. Noms de fonctions non descriptifs. Noms de classe trop ornés. Marquage des noms de variable avec leur type (par exemple, b_isCounted pour une variable booléenne). Et pire encore, mélanger différents systèmes de nommage dans une même base de code. Tous ces éléments génèrent un code difficile à lire, à comprendre et à gérer.

La solution
Choisir de bons noms pour les variables, les fonctions et les classes est une compétence difficile à maîtriser. Si vous rejoignez un projet existant, parcourez-le et voyez comment les identifiants existants sont nommés. S'il existe un guide de style, mémorisez-le et respectez-le. Pour les nouveaux projets, envisagez de créer votre propre guide de style et respectez-le..

En général, les noms de variables doivent être courts mais descriptifs. Les noms de fonctions doivent généralement avoir au moins un verbe et il devrait être immédiatement évident de voir ce que la fonction fait juste à partir de son nom, mais évitez de surcharger de mots. Il en va de même pour les noms de classe.

6. numéros magiques

Le problème
Vous parcourez un code écrit (espérons-le) par quelqu'un d'autre et vous repérez des numéros codés en dur. Cela fait peut-être partie d'une déclaration if, ou peut-être de calculs arcaniques qui ne semblent pas avoir de sens. Vous devez modifier la fonction, mais vous ne pouvez tout simplement pas comprendre le sens des chiffres. Tête de queue gratter.

La solution
En écrivant du code, ces soi-disant “nombres magiques” devrait être évité à tout prix. Les nombres codés en dur ont du sens au moment de leur rédaction, mais ils peuvent rapidement perdre tout leur sens, surtout lorsque quelqu'un d'autre essaie de conserver votre code.

Une solution consiste à laisser des commentaires expliquant le nombre, mais la meilleure option consiste à convertir des nombres magiques en variables constantes (pour les calculs) ou en énumérations (pour les instructions conditionnelles et les instructions switch). En donnant un nom aux nombres magiques, le code devient infiniment plus lisible en un coup d’œil et moins sujet aux changements de boguets.

7. nidification en profondeur

Le problème
Il existe deux manières principales de se retrouver avec un code profondément imbriqué: les boucles et les instructions conditionnelles. Le code profondément imbriqué n'est pas toujours mauvais, mais peut être problématique, car il peut être difficile à analyser (surtout si les variables ne sont pas bien nommées) et encore plus difficile à modifier..

La solution
Si vous vous trouvez en train d'écrire une boucle double, triple ou même quadruple, alors votre code essaie peut-être d'aller trop loin en dehors de lui-même pour trouver des données. À la place, indiquez un moyen de demander les données via un appel de fonction, quel que soit l'objet ou le module contenant les données..

D'autre part, les instructions conditionnelles profondément imbriquées indiquent souvent que vous essayez de gérer trop de logique dans une seule fonction ou une seule classe. En fait, la nidification en profondeur et les longues fonctions ont tendance à aller de pair. Si votre code contient des instructions switch massives ou des instructions imbriquées if-then-else, vous pouvez implémenter un modèle de machine d'état ou de stratégie..

La nidification en profondeur est particulièrement répandue parmi les programmeurs de jeux inexpérimentés. 5 outils logiciels de développement de jeux gratuits pour créer vos propres jeux. 5 outils de logiciels de développement de jeux gratuits pour créer vos propres jeux. Voici les meilleurs logiciels et outils de développement de jeux gratuits que vous pouvez utiliser pour commencer à créer le jeu de vos rêves. aujourd'hui. Lire la suite !

8. Exceptions non gérées

Le problème
Les exceptions sont puissantes mais facilement abusées. Les programmeurs paresseux qui utilisent de manière incorrecte les instructions throw-catch peuvent rendre le débogage exponentiellement plus difficile, voire impossible. Par exemple, ignorer ou enterrer des exceptions interceptées.

La solution
Au lieu d'ignorer ou d'enterrer les exceptions interceptées, imprimez au moins la trace de pile de l'exception pour permettre aux débogueurs de travailler avec quelque chose. Laisser votre programme échouer en silence est une recette pour les maux de tête futurs, c'est garanti! Préférez également intercepter des exceptions spécifiques par rapport aux exceptions générales. Pour en savoir plus, consultez notre article sur la gestion correcte des exceptions. Comment gérer les exceptions Java de la bonne manière Comment gérer correctement les exceptions de Java Dans cet article, vous apprendrez ce que sont les exceptions Java, pourquoi elles sont importantes, comment utilisez-les et évitez les erreurs courantes. Lire la suite .

9. Code en double

Le problème
Vous effectuez la même logique exacte dans plusieurs zones non liées de votre programme. Plus tard, vous réalisez que vous devez modifier cette logique, mais vous ne vous souvenez pas de tous les endroits où vous l'avez implémentée. Vous finissez par le changer à seulement 5 endroits sur 8, ce qui entraîne des comportements incohérents et incohérents..

La solution
Le code en double est un candidat idéal pour être transformé en une fonction. Par exemple, supposons que vous développiez une application de chat et que vous écriviez ceci:

String queryUsername = getSomeUsername (); boolean isUserOnline = false; for (String nom d'utilisateur: onlineUsers) if (nomutilisateur.equals (queryUsername)) isUserOnline = true;  if (isUserOnline) …

Quelque part ailleurs dans le code, vous réalisez que vous devez effectuer la même chose. “cet utilisateur est en ligne?” vérifier. Au lieu de copier-coller la boucle, vous pouvez l'extraire dans une fonction:

public boolean isUserOnline (String queryUsername) pour (String nom d'utilisateur: onlineUsers) if (nomutilisateur.equals (queryUsername)) return true;  return false; 

Désormais, n'importe où dans votre code, vous pouvez utiliser la vérification isUserOnline (). Si vous avez besoin de modifier cette logique, vous pouvez modifier la méthode et elle s'appliquera partout où elle s'appelle..

10. Manque de commentaires

Le problème
Le code n'a absolument aucun commentaire nulle part. Pas de blocs de documentation pour les fonctions, pas d'aperçu d'utilisation pour les classes, pas d'explications sur les algorithmes, etc. On pourrait soutenir qu'un code bien écrit n'a pas besoin de commentaires, mais la vérité est que même le code le mieux écrit nécessite toujours plus d'énergie mentale comprendre que l'anglais.

La solution
L’objectif d’une base de code facile à maintenir doit être un code suffisamment écrit pour ne pas avoir besoin commentaires, mais les a toujours. Et lors de la rédaction des commentaires, visez des commentaires qui expliquent Pourquoi un extrait de code existe au lieu d'expliquer quoi c'est faire. Les commentaires sont bons pour l'âme et la santé mentale. Ne les néglige pas.

Comment écrire un code qui ne sent pas

Aussi évident que cela puisse paraître, la plupart des odeurs de code proviennent d'une incompréhension ou d'une négligence de bons principes et modèles de programmation. 10 Principes de base de la programmation que chaque programmeur doit suivre. 10 Principes de base de la programmation que chaque programmeur doit suivre. travailler sur votre logiciel. À cette fin, voici plusieurs principes de programmation pour vous aider à nettoyer votre acte. Lire la suite . Par exemple, une adhésion solide au principe DRY élimine la plupart des duplications de code, tandis que la maîtrise du principe de responsabilité unique rend presque impossible la création d'objets monstrueux de Dieu..

Nous vous recommandons également de lire notre article sur la rédaction de code plus propre. 10 Conseils pour écrire du code plus propre et plus performant 10 Conseils pour écrire du code plus propre et plus performant L'écriture de code propre a l'air plus facile qu'elle ne l'est réellement, mais les avantages en valent la peine. Voici comment vous pouvez commencer à écrire du code plus propre aujourd'hui. Lire la suite, qui examine un aspect plus pratique de la programmation. Si vous ne pouvez pas lire votre propre code et le comprendre d'un coup d'œil, comment va quelqu'un d'autre? Un code propre est un code sans odeur.

Avec quoi luttez-vous le plus en matière de programmation? Partagez avec nous dans les commentaires ci-dessous!

Crédit d'image: SIphotography / Depositphotos

En savoir plus sur: Programmation.