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

Partagez votre expérience

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 ?