Quelles sont les pires habitudes qui conduisent à l'écriture d'un mauvais code ?
Partagez votre expérience

Le , par Michael Guilloux, Chroniqueur Actualités
Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ?
Beaucoup de développeurs passionnés aiment dire que coder est un art. Et si c’est le cas, c’est surement parce qu’il ne suffit pas d’écrire un code qui marche. Il y a un certain nombre de règles et bonnes pratiques – qui se développent parfois avec l’expérience – qui permettent de le faire de manière optimale. Celles-ci aident à écrire un code propre, maintenable, évolutif, et surtout en tenant compte des délais fixés. Déroger à ces règles, que ça soit par méconnaissance ou volontairement, peut donc conduire à un code de mauvaise qualité qui pourrait vous classer dans le groupe des mauvais développeurs.

Au lieu de s’interroger sur les bonnes pratiques de programmation, comme nous l’avons fait plusieurs fois ici, on peut aujourd’hui aborder le problème sous un autre angle. Quelles sont les habitudes qui caractérisent un mauvais développeur ou qui vous amèneront à écrire un code de mauvaise qualité ? la liste est certainement longue, mais on peut citer les habitudes suivantes comme point de départ :

  • vouloir réinventer la roue tout le temps. Avec 99 % de chance, votre problème a déjà été résolu quelque part. Pourquoi donc ne pas googler quand le problème vous semble complexe ?
  • être un développeur orienté copier/coller. Il ne faut pas copier/coller aveuglément. Il est nécessaire d’essayer de comprendre le code d’abord, car il est possible qu’il ne fasse pas exactement ce qu’il prétend faire ;
  • être focalisé sur le codage. Le codage proprement dit n’est pas la chose sur laquelle les développeurs passent le plus de temps. Il faut donc prendre du temps sur la manière de résoudre les problèmes avant de se jeter sur son clavier ;
  • utiliser des noms ne donnant aucune information sur ce que fait le code. Un nom de fonction par exemple est censé donner une idée de ce que fait le bout de code. Dans le cas contraire, ça devient difficile de le relire, parce qu'il faut aller dans les détails pour savoir ce qu’il fait ;
  • vouloir à tout prix minimiser le nombre de lignes de son code. Être obsédé par le fait d'avoir des codes courts peut vous amener à sacrifier la lisibilité de votre code ;
  • ignorer les messages d’erreur. La plupart du temps, les messages d’erreur vous donnent suffisamment d’informations pour avoir une idée de ce qui ne va pas avec votre code. Il ne faut donc pas supposer quand vous avez une erreur dans votre code que vous savez ce qui ne va pas sans lire d’abord attentivement le message d’erreur. Sinon, vous risquez de perdre plus de temps ;
  • s’entêter à vouloir résoudre des problèmes sans demander de l’aide ;
  • toujours reporter la correction des bogues ;
  • vouloir traiter tous les problèmes avec un seul outil. Il n'existe pas de véritable couteau suisse en programmation. Il faut donc avoir plusieurs cordes à son arc et ne pas se figer à un seul outil, un seul langage ou une seule technologie. Quand on a qu’un marteau comme outil, on a en effet tendance à voir tous les problèmes comme des clous ;
  • ignorer les forces et limites des outils que vous utilisez ;
  • ne pas documenter ou commenter son code ;
  • ignorer les tests unitaires ou les considérer comme une tâche secondaire ;
  • ignorer les pratiques de développement éprouvées : revue de code, test-driven development (TDD), assurance qualité (QA), etc. ;
  • ne pas aimer la lecture (documentation, aide en ligne, etc.) ;
  • vouloir optimiser le code dès le début. Il n’est pas nécessaire de chercher à optimiser son code dès le début pour faire face à toute sorte de scénarios possibles. Ce travail devrait être gardé pour la fin. Le plus souvent les exigences telles que définies au début peuvent changer. Vous aurez donc perdu du temps à vouloir optimiser votre code dès le début, et adapter le code optimisé aux nouvelles exigences peut générer plus d’erreurs ;
  • ne pas maitriser ses outils et langages de développement. Si les outils et langages que vous utilisez régulièrement sont encore assez mystérieux pour vous, c’est un signe que vous les utilisez probablement mal. Que doit-on donc espérer du résultat ?
  • considérer les codes simples comme des codes d’amateur. Écrire un code simple et être à l’affût de simplification dans son code n’est pas forcément un signe d’amateurisme. Au contraire, cela peut-être la meilleure manière d’écrire un code propre et maintenable ;
  • ne pas explorer quelques pistes avant de demander de l’aide. Avant de solliciter de l’aide sur un problème, il faudrait essayer de le résoudre d’abord et explorer plusieurs pistes qui n’ont pas marché. Cela vous permet de mieux apprécier la solution qui vous est fournie et l’améliorer si nécessaire.


Et vous ?

Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ? Partagez votre expérience
Lesquelles rencontrez-vous souvent ?
Quels sont les éléments qui manquent selon vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de tp1024 tp1024 - Membre habitué https://www.developpez.com
le 22/06/2017 à 11:04
J'ajouterai le critère selon moi le plus important:

Ne coder que le cas nominal et planifier le codage des cas particulier et la gestion des erreurs à la fin du codage.

Autre critère: ne pas factoriser le code.
Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 22/06/2017 à 11:44
Citation Envoyé par tp1024 Voir le message
Autre critère: ne pas factoriser le code.
Correction :
Autre critère: ne pas factoriser le code tout de suite mais à la fin.

Parce que sinon c'est une habitude à écrire un code de mauvaise qualité et difficilement maintenable.
Avatar de John Bournet John Bournet - Membre averti https://www.developpez.com
le 22/06/2017 à 12:16
Je dirais le syndrome de la décharge (ou du carreau cassé) : s'autoriser un petit écart, une verrue qui va rester, qui va grossir avec le temps et les évolutions apportées. Au final, si le bout de code est mauvais, chacun viendra rajouter ses déchets dans l'esprit de l'existant.
Moralité, c'est une mauvaise habitude de laisser le code de mauvaise qualité vivre.
Avatar de Lcf.vs Lcf.vs - Membre éprouvé https://www.developpez.com
le 22/06/2017 à 12:53
Citation Envoyé par Michael Guilloux Voir le message

[*]vouloir optimiser le code dès le début. Il n’est pas nécessaire de chercher à optimiser son code dès le début pour faire face à toute sorte de scénarios possibles. Ce travail devrait être gardé pour la fin. Le plus souvent les exigences telles que définies au début peuvent changer. Vous aurez donc perdu du temps à vouloir optimiser votre code dès le début, et adapter le code optimisé aux nouvelles exigences peut générer plus d’erreurs ;
Suis pas tout à fait d'accord sur ce point, moi. Autant le principe est correct, autant dans la réalité du métier, ce n'est pas viable.

Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.

Perso, sur base de plus de 10 ans à aider du monde qui n'a pas le temps de faire du propre, je pars du principe que si un code n'est pas bien écrit dès le départ, il ne le sera jamais.

C'est juste le meilleur moyen d'avoir une usine à gaz avec plein de conventions de codage différentes & Co.

Alors, oui, avoir des process qui changent, ça arrive souvent mais ce qui génère davantage d'erreurs, c'est généralement que les développeurs font des rustines sur des trucs déjà pas trop bien pensés à l'origine ou pour lesquels on a pas donné assez de temps pour avoir du travail de qualité.
Avatar de Michel Rotta Michel Rotta - Expert éminent https://www.developpez.com
le 22/06/2017 à 13:02
Considérer qu'il n'y a jamais d'erreurs possibles et donc ne jamais vérifier les données en entrée ou les échanges avec d'autres outils (méthode dite du Bisounours).
Avatar de Jbx 2.0b Jbx 2.0b - Membre expérimenté https://www.developpez.com
le 22/06/2017 à 13:18
- Ne pas respecter les règles de codage (syntaxe, nommage) formalisées par l'équipe. Pire: ne pas en avoir soit même, et jongler avec la casse, les indentations, la ponctuations, au petit bonheur la chance.
- Ne pas prendre le temps pour donner des noms explicites qui décrivent clairement ce que fait l'objet ou la méthode.
- Utiliser des abréviations.
- Ne pas connaitre et mettre en oeuvre les design patterns les plus courants.
- Violer le pattern MVC, en général en exposant la vue au modèle (y a des projets énormes dans des grandes boîtes basé sur ce péché originel).
- Etre trop feignant pour refactoriser immédiatement un code lorsque l'on détecte une des erreurs sus mentionnées.
- Procrastiner les bugs, la gestion d'erreur, les tests...
Avatar de smetairie smetairie - Nouveau membre du Club https://www.developpez.com
le 22/06/2017 à 14:01
Meme si les grandes lignes des pires habitudes du sondage sont pertinentes, je trouve que tout est une affaire de contexte. Parfois vous devez faire du code "quick&dirty". Parfois il faut avoir un vrai framework robuste.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 22/06/2017 à 14:44
Citation Envoyé par transgohan Voir le message
Correction :
Autre critère: ne pas factoriser le code tout de suite mais à la fin.

Parce que sinon c'est une habitude à écrire un code de mauvaise qualité et difficilement maintenable.
Ca, c'est mon collègue, qui trouve que je me complique toujours la vie avec mes fonctions, là ou un simple posé de code copié-collé-adapté suffit à ses yeux..... Le pire, c'est que son code marche, mais le jour ou on a une modif majeure, on pleure.
Avatar de CaptainDangeax CaptainDangeax - Membre averti https://www.developpez.com
le 22/06/2017 à 14:47
Développeur ce n'est pas mon métier, mais j'écris pas mal de scripts en bash. C'est pratique pour les tests unitaires : il y a la console. Factoriser tout de suite, c'est une bonne habitude à prendre. En cas de modification, ça évite d'avoir à modifier plusieurs fois dans le code la même chose.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 22/06/2017 à 14:49
Citation Envoyé par Lcf.vs Voir le message
Le plus souvent, on vous donne une mission à remplir, ainsi qu'un délai pour le faire. Si le code produit à l'échéance de ce délai n'est pas optimisé, l'employeur ou le client décidera généralement de zapper cette phase d'optimisation, après tout, ça tourne déjà, voire ça rapporte déjà, cela représente donc, pour lui, une dépense inutile ou juste annoncée comme du "on verra plus tard" qui n'arrive jamais.
A mon sens, ça dépend de ce qu'on appelle "optimiser". Si c'est juste rajouter un tri préliminaire et un bête buffer pour limiter les I/O sur un traitement de masse, oui, c'est mieux de le faire au début. Si c'est penser son système pour ne pas avoir de redondances d'exécutions, oui c'est mieux d'y penser dès le début. Si c'est aller chercher des méthodes de sioux via des pointeurs pour forcer le compilateur à une manip nettement plus compliquée, là, il vaut mieux le faire vers la fin, et uniquement là ou on a identifié des fortes consommations.
Contacter le responsable de la rubrique Accueil