IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

62PARTAGES

22  0 
Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ?
utiliser des noms ne donnant aucune information sur ce que fait le code
73 %
ne pas documenter ou commenter son code
48 %
être un développeur orienté copier/coller
44 %
ne pas maîtriser ses outils et langages de développement
40 %
ignorer les messages d’erreur
40 %
ignorer les pratiques de développement éprouvées
39 %
vouloir réinventer la roue tout le temps
37 %
toujours reporter la correction des bogues
35 %
vouloir à tout prix minimiser le nombre de lignes de son code
34 %
considérer les codes simples comme des codes d’amateur
34 %
ne pas aimer la lecture (documentation, aide en ligne, etc.)
31 %
s’entêter à vouloir résoudre des problèmes sans demander de l’aide
29 %
ignorer les tests unitaires ou les considérer comme une tâche secondaire
29 %
ignorer les forces et limites des outils que vous utilisez
24 %
être focalisé sur le codage
24 %
vouloir optimiser le code dès le début
21 %
ne pas explorer quelques pistes avant de demander de l’aide
19 %
vouloir traiter tous les problèmes avec un seul outil
11 %
Autre (à préciser)
5 %
Pas d'avis
2 %
Voter 62 votants
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 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.
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 22/06/2017 à 17:14
Sur la réutilisation : la classique réponse de Joel Spolsky :

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.
6  0 
Avatar de Lcf.vs
Membre éclairé 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é.
6  1 
Avatar de 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).
5  0 
Avatar de Jbx 2.0b
Membre chevronné 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...
5  0 
Avatar de 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.
4  1 
Avatar de
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.
3  0 
Avatar de pcdwarf
Membre éprouvé https://www.developpez.com
Le 26/06/2017 à 11:27
Je trouve qu'il y a une contradiction entre 2 défauts.

"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 ;"

Personellement, j'ai un mal fou à rentrer dans le code de quelqu'un d'autre.
Surtout quand ce code n'est pas documenté/commenté et que ce code contient "de l'historique" (c'est à dire des bouts inutiles résidus d'une évolution du besoin)
Un cas classique est le code bien commenté au niveau détail (merci mais je connais le langage, inutile de m'expliquer ligne à ligne) alors que la démarche globale n'apparait pas.

Résultat, je réinvente souvent la roue parce que ça va au final beaucoup plus vite que de s'approprier une solution existante.
Ou alors on tombe dans l'autre travers qui est de copier-coller sans comprendre en priant pour que ça marche...
Je déteste tout particulièrement ça parce qu'en général, ça ne marche pas.
3  0 
Avatar de 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.
2  0 
Avatar de 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.
2  0