Quelles sont les habitudes qui peuvent vous amener à écrire un code de mauvaise qualité ?

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 ?

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

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.

Citation:

---

Envoyé par tp1024

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. ;)

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.

Citation:

---

Envoyé par Michael Guilloux

[*]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é.

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

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

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.

Citation:

---

Envoyé par transgohan

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.

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.

Citation:

---

Envoyé par Lcf.vs

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.

Citation:

---

Envoyé par Michael Guilloux

[*]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 ?

---

A moitié vrai.
La multiplication des solutions fait qu'on passe de plus en plus de temps à chercher quelquechose, à éplucher les documentations, voir les avis et a tester si ca fonctionne dans notre cas...
Bref c'est de plus en plus chiant de "développer" parcequ'on devient de plus en plus des "assembleurs", et surtout en terme de maintenance je crois qu'on y perd.
En effet lorsqu'on se retrouve a récupérer un projet qui fait reference à x librairie dont on a jamais entendu parler et qu'il y a un soucis, ou une demande d'evolution, il faut non seulement comprendre notre code mais egalement s'assurer que la librairie est "bien" utilisée. Dans le pire des cas on se rend meme compte que cette librairie possède un bug, et que la librairie est abandonnée:aie:.

Vouloir réinventer la roue tout le temps

Pas d'accord sur ce point précisément.
Si on prend effectivement dans un cadre très précis de programmation et de contexte d'entreprise (avec délais de livraison très courts, contraintes à n'en plus finir, besoin sans cesse de gain de productivité), en effet, savoir utiliser l'existant permet de gagner de précieuses minutes et de fournir le travail dans les temps.

Mais en prenant le codage d'un point de vue globale, dans un ensemble, c'est ô combien important de ré-inventer la roue. Je rappelle que ce sont des gens qui un jour se sont dit "moi, je peux refaire ce système, mais en mieux" qui sont à l'origine des innovations de notre temps. Et c'est parce que nombre de développeurs ont ré-inventé la roue que nous avons autant de choix de logiciels, systèmes, de jeux vidéo, et j'en passe.

Il suffit de voir par exemple le cas des blogs WordPress. Si tout le monde installe exactement le même type de blog, les mêmes plugins, le même thème....on finira avec des clones, des projets sans aucune différence et une réelle perte d'identité pour ces derniers. À un moment donné, il faut bien ré-inventer quelque chose...ou partir d'une base que l'on améliore (mais cette amélioration, dans 99% des cas, existe sûrement déjà aussi).

Étant formateur en informatique sur internet, c'est un point que j'aborde très souvent auprès de mon audience. Si vous travaillez dans des conditions précises et imposées, vous n'avez pas le temps de ré-inventer. Faîtes avec ce qui existe déjà et le client sera content. Mais pour celui qui code dans son coin, par véritable passion, ou est libre de travailler dans le temps qu'il lui convient, c'est souvent un réel gain d'expérience et de plaisir que de ré-inventer ce qui se fait déjà =).

PS : je rajouterai que, de nos jours, les développeurs dans les entreprises (pas toutes heureusement) ne sont plus vraiment des développeurs ou programmeurs, mais des personnes qui apprennent à prendre en main des logiciels et des traitements automatisés, pour assembler tout ça et espérer que ça fonctionne. J'ose espérer que dans 10 ans, il existera encore des gens qui se poseront la question de s'il est possible de ré-inventer un système de tri qui sera plus performant que les actuels, ou d'autres algorithmes du genre qui sont toujours améliorables ou re-faisables.

Citation:

---

Envoyé par Lcf.vs

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.

---

Tout dépend quel est l'utilisation du code en question.
Parfois, le besoin est juste d'avoir une fonctionnalité qui effectue le service demandé.
Pas besoin que ça soit beau ou optimisé ou même évolutif.
Le quick and dirty peut parfaitement correspondre.
Ce n'est pas pour rien qu'Excel est si utilisé en entreprise.
L'idée peut être simplement d'aller vite et pas cher.
Je sais que ça peut paraître irritant aux oreilles de développeurs chevronnés et passionnés mais cela est parfaitement sensé du côté client.


Dans d'autres cas, les perf. du programmes sont au moins aussi importantes que ses fonctions.
Et là, je peux dire que les clients payent sans rechigner pour optimiser le code.
Je pense notamment à des programmes très fortement sollicités et souvent en appel direct par les clients réels de l'entreprise.
Par contre, dans ces cas là, le besoin en perf est clairement spécifié dans le CDC et la conception en tient compte dès le départ.
Les optimisation viennent suite aux observations effectués lors de tirs de charge et autres stress tests.

Sur la réutilisation : la classique réponse de Joel Spolsky :

Citation:

---

If it’s a core business function — do it yourself, no matter what.

---

En d'autres termes, si vous êtes un hopital, réutilisez un logiciel pour le café. Mais si vous êtes Starbucks, faites-le vous-même.

Citation:

---

Envoyé par Michael Guilloux

ê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

---

Ce commentaire s'applique à ceux qui pompent du code sur internet. Mais, les pires développeurs orientés copier-coller, ce sont ceux qui copient-collent en masse de gros morceaux de code de leur propre programme au lieu de factoriser. Le pire exemple que j'ai vu était un copié-collé d'une fonction de plus de 1000 lignes.

Citation:

---

Envoyé par tp1024

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

---

Pire : ne coder que le cas nominal, se barrer dans une autre boîte et laisser souffrir ceux qui reprendront le code. Déjà vu.

Citation:

---

Envoyé par Lcf.vs

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.

---

Ce n'est pas forcément un problème. Si on se met à la place de l'utilisateur, il est parfois plus important qu'une certaine fonctionnalité soit disponible tôt plutôt que le programme soit optimisé.
Ce qui est important, c'est que le code soit correctement architecturé pour qu'il soit facile d'optimiser plus tard, si le client en a vraiment besoin, par exemple si un traitement devient trop lent ou échoue car consomme trop de mémoire.

Citation:

---

Envoyé par Jbx 2.0b

- Utiliser des abréviations.

---

Abuser des abréviations est une mauvaise pratique, mais en utiliser est parfois justifié.
Par exemple, pour éviter des collisions de noms, une bonne manière est d'utiliser un préfixe spécifique au projet.
Comme ce préfixe doit être unique mais préférentiellement court, utiliser une abréviation peut être une bonne idée.
Remarque : Dans les langages qui supportent les espaces de nom, c'est l'espace de nom qui joue le rôle du préfixe.

Citation:

---

Envoyé par Michael Guilloux

:fleche: Quels sont les éléments qui manquent selon vous ?

---

Les deux points suivants relèvent plus de la conception que du codage, mais les voici quand même :

:fleche: Être trop permissif dans les données en entrée et les accepter sans signaler d'erreur ou, au moins, d'avertissement.
Exemples :

• Un fichier en entrée n'est pas au bon format. Pas grave : on ajoute plein de conditions dans le code pour réussir à le lire quand même dans un maximum de cas possibles.
• Une configuration indique qu'un certain dossier a une certaine adresse, mais le programme constate que ce dossier ne contient pas certains fichiers qu'il aurait dû contenir si la configuration était cohérente avec l'installation. Pas grave : on va chercher les fichiers, successivement, dans plein d'autres dossiers différents. On finira peut-être par les trouver.

Du coup, l'analyse des problèmes devient laborieuse et le code devient plus complexe, ce qui ralentit l'ajout de nouvelles fonctionnalités et augmente la fréquence d'apparition de nouveaux bogues.

:fleche: Utiliser des données utilisateurs comme des clefs primaires dans les bases de données.
Exemple intéressant : https://www.developpez.net/forums/d8...s/#post5745847

Sachant que je prend rarement le chemin le plus court ni le plus efficace, je dirais :
- aller à l'essentiel
- toujours vérifier les saisies utilisateur, exemple d'un formulaire web, si les valeurs autorisés sont A, B ou C, aucune autre valeur ne doit être acceptée,
- toujours séparer le traitement de l'affichage,
- ne pas réinventer la roue.

Etant le seul développeur, j'ai personne pour vérifier mon code et pour me taper sur les doigts :roll:
Au contraire, je suis très attaché à la qualité et être seul nécessite beaucoup plus de rigueur (pas toujours évident quand il y a une deadline serrée, et là c'est de la doc qui passe à la trappe ou l'optimisation de certaines fonctions).

J'ai voté pour ces propositions :

• être un développeur orienté copier/coller
• utiliser des noms ne donnant aucune information sur ce que fait le code
• s’entêter à vouloir résoudre des problèmes sans demander de l’aide
• ne pas documenter ou commenter son code

Critères que je rencontre parfois avec des stagiaires (que je met forcément sur le compte de l'expérience).

Ou même de l'ancien développeur : du style à faire 1 fichier de 1900 lignes de fonctions et ne mettre qu'un seul commentaire en haut de page totalement inutile « Regroupe toutes les fonctions de l'application » OK MERCI :aie:

optimiser du code dans une architecture logicielle pensée optimisation des perfs des la conception est essentielle et largement plus utile que coder en moins de lignes de codes possibles.
Pour ca qu'en 2017 je ne comprends pas pourquoi M$ par exemple continuer a inventer des syntaxes dans les nouvelles versions C# pour passer de 3 lignes de code a 2. Ca ne fait absolument rien gagner, ca ne simplifie pas la maintenance -car tout le monde n'est pas forcement interessé de connaitre la derniere petite syntaxe inutile.
Je vois trop souvent dans ma boite des gens qui pissent litteralement du code puis repasse par des etapes de refactoring. Souvent passer plus de temps en amont dans la conception est plus efficace que defaire/refaire apres. Enfin le refactoring est a la mode c'est donc que les dev ne concoivent pas mais se jettent sur le clavier et refont quand c'est au pied du mur avec un soft mal concu.
je viens de l'assembleur/c/c++ donc j'ai toujours appris a penser optimiser logiciel en premier (a une epoque (1989), on desassemblait meme le C 68000 pour le modifier afin d'arriver a un code machine le plus simple). Maintenant on ne se fait plus chier, new() a tour de bras, il y aura bien quelqu'un (GC) qui fera le boulot (le dev est devenu faineant et faire un delete() est trop compliqué).
Ca me fait rire quand je vois les sujets de discussion type 'optimisation du code : foreach ou for' ? A une epoque ou dans les langages on fait des new() a tour de bras. C'est le genre de discussion totalement inutile (qui meme si elle etait vraie ne ferait rien gagner quasiment alors qu'un logiciel un peu mieux concu suffirait a optimiser les perfs - independamment de la facon d'ecrire du code).
Le langage est un support pas une fin en soi. Alors se faire plaisir pour faire du code "beau"...
Seulement entre temps on a perdu le 'comment ca marche' et des qu'il y a pb de perfs ou bugs c'est la paanique car la mecanique de base n'est pas maitrisée (inspiration du code piqué sur internet le plus souvent). En 2017 la regle du devp moderne c'est copier/coller et stackoverflow.

J'ai vu des soi disants tres bons programmeurs (code illisible en WPF par exemple). Par contre un logiciel qui est une merde en maintenance.
La maintenabilité du code par quiconque est pour moi la 2eme chose essentielle (sans pour autant que celui qui passe derriere n'ai a connaitre les dernieres syntaxes a la mode - qui ne feront pas executer le code plus vite pour autant). Finie l'epoque du basic ou on enlevait les commentaires pour gagner en vitesse d'execution.

Pour ce qui est revu de code (ou validation des pulls requests), je ne passe pas derriere mes collegues car j'estime qu'en etant ingenieurs ils doivent s'appliquer un minimum d'exigences. Ce n'est pas a moi d'aller verifier qu'ils ont mis les bons noms de variables, coder correctement le fonctionnel etc.
ils ont une tache, elle doit etre remplie parfaitement. point barre.
Un gars qui fait du code de merde ca se voit vite sur une prod donc generalement ca se termine en 'tu corriges tes merdes quittes a venir bosser le samedi, car maintenant c'est ton probleme' sinon tu n'as pas ta place ici. J'estime qu'un gars payé a un certain niveau de salaire est redevable d'une certaine qualité dans le travail rendu et ce n'est pas a l'equipe d'essuyer les platres a sa place.
Ca fonctionne, les devps s'imposent un travail de verification/relecture qui paie.

Citation:

---

Envoyé par kilroyFR

optimiser du code dans une architecture logicielle pensée optimisation des perfs des la conception est essentielle et largement plus utile que coder en moins de lignes de codes possibles.

---

Oui c'est vrai, au passage, les perfs dépendent du projet en question.

A moins de faire de gros calculs pointus, de l'IA, 3D et j'en passe, la plupart des projets plus "classiques" seront sensibles à une chose : faire un minimum d'appels BDD puisque une requête SQL (même simple) ou un appel WebService c'est 500ms à plus d'une seconde de perdue sur un environnement de production.

Je ne dis pas de coder avec les pieds, cela étant, passer par des variables intermédiaires, ou déclarer 2, 3 variables pas très utiles ont pas forcément un impact capital sur les perfs.

2 points sur le développement web
- toujours séparer traitement et présentation, les appels BDD ne doivent pas être disséminés partout dans le code,
- ne jamais mélanger du code client avec un langage serveur.

Ne pas respecter ces règles c'est dire au revoir à des tests unitaires.