Affichage des résultats du sondage: Quelles sont les pires habitudes qui conduisent à l’écriture d’un mauvais code ?

Votants
58. Vous ne pouvez pas participer à ce sondage.
  • vouloir réinventer la roue tout le temps

    20 34,48%
  • être un développeur orienté copier/coller

    26 44,83%
  • être focalisé sur le codage

    15 25,86%
  • utiliser des noms ne donnant aucune information sur ce que fait le code

    44 75,86%
  • vouloir à tout prix minimiser le nombre de lignes de son code

    19 32,76%
  • ignorer les messages d’erreur

    24 41,38%
  • s’entêter à vouloir résoudre des problèmes sans demander de l’aide

    16 27,59%
  • toujours reporter la correction des bogues

    21 36,21%
  • vouloir traiter tous les problèmes avec un seul outil

    7 12,07%
  • ignorer les forces et limites des outils que vous utilisez

    14 24,14%
  • ne pas documenter ou commenter son code

    29 50,00%
  • ignorer les pratiques de développement éprouvées

    22 37,93%
  • ne pas explorer quelques pistes avant de demander de l’aide

    10 17,24%
  • ignorer les tests unitaires ou les considérer comme une tâche secondaire

    17 29,31%
  • ne pas aimer la lecture (documentation, aide en ligne, etc.)

    17 29,31%
  • vouloir optimiser le code dès le début

    11 18,97%
  • ne pas maîtriser ses outils et langages de développement

    24 41,38%
  • considérer les codes simples comme des codes d’amateur

    20 34,48%
  • Autre (à préciser)

    3 5,17%
  • Pas d'avis

    1 1,72%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Membre expérimenté Avatar de Jbx 2.0b
    Homme Profil pro
    Développeur Qt/3D
    Inscrit en
    septembre 2002
    Messages
    445
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Qt/3D
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : septembre 2002
    Messages : 445
    Points : 1 667
    Points
    1 667

    Par défaut

    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.
    En fait on imagine pas à quel point aujourd'hui les compilateurs / interpréteurs sont capables d'optimiser le code. Ça vaut le coup de les aider dans des cas bien particuliers (ex: paralléliser des boucles), et bien sur ils ne rattraperont jamais un choix d'architecture foireuse. Mais la plupart du temps ils ignorent littéralement toutes nos petites manipulations, et les remplacent par leurs optimisations bien à eux qu'on aurait jamais soupçonnées !

  2. #22
    Membre éclairé Avatar de pcdwarf
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    février 2010
    Messages
    213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2010
    Messages : 213
    Points : 735
    Points
    735

    Par défaut

    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. #23
    Membre émérite
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 374
    Points : 2 276
    Points
    2 276

    Par défaut

    "optimiser depuis le début"

    Au contraire je trouve que c'est une bonne chose.
    Cela voudra dire que du début à la fin du développement, le dévéloppeur aurait fait un effort d'optimisation.

    Il est pire d'écrire tout à la va vite, en ne regardant pas si des variables sont inutiles, des méthodes publiques non nécessaires... et ensuite se retrouver avec un programme lourd dingue.
    Optimiser à ce moment là sera nécessaire mais trop tard.

    Il faut optimiser avant que le besoin ne se fasse sentir.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  4. #24
    Membre émérite
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 374
    Points : 2 276
    Points
    2 276

    Par défaut

    Citation Envoyé par CaptainDangeax Voir le message
    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.
    J'ai déjà quelques batch à mon actif mais n'en suis pas un gourou.
    Il est très facile de faire un petit script utile. Ensuite on peut rediriger les entrées / sorties... mais ça devient vite la m* lorsque l'on veut simplifier le code et qu'il y a des redirections, appels dans tous les sens. C'est complètement différent de développer en bash.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  5. #25
    Membre éclairé Avatar de pcdwarf
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    février 2010
    Messages
    213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2010
    Messages : 213
    Points : 735
    Points
    735

    Par défaut

    "optimiser depuis le début"

    Au contraire je trouve que c'est une bonne chose.
    Cela voudra dire que du début à la fin du développement, le dévéloppeur aurait fait un effort d'optimisation.
    Oui et non.
    Disons que ça dépends de ce que tu entends par "optimisation".

    Pour prendre les deux extrèmes des exemples usuellement cités :
    - Le mec qui a plein de code mort, des variables inutilisées en pagaie et qui n'hésites pas a faire faire des trucs lourdingues du genre copier des grands tableaux dans des variables temporaires juste pour éviter de réfléchir 30 secondes c'est juste un porc.
    - Mais le gars qui passe son temps a se demander si son echo doit avoir des simples quotes pour gagner le temps d'interprétation de la chaine, ou d'autre trucs du même genre que le compilateur sait très bien optimiser automatiquement, c'est de la branlette cérébrale qu'il fait.

    Par contre, il y a des choses dont on sait dès le départ qu'elles poseront un problème de perf si on s'y prends mal. Et là ça vaut le coup de réfléchir dès le départ pour éviter de se retrouver plus tard avec un complexité en factorielle N et de devoir tout jeter et tout refaire.

    Le nombre de types que j'ai vu se demander si il vallait mieux mettre un for ou un while alors que leur algo avait inutilement une complexité en N²...

  6. #26
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    604
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 604
    Points : 1 056
    Points
    1 056

    Par défaut

    Hum, perso, lorsque je parle d'optimisation, je ne parle pas que de perfs mais aussi d'optimisation de réutilisation, d'extensibilité, ... Si on optimise pas cela dès le départ, ça revient souvent à devoir tout réécrire et encore pire si on a d'autres composants qui en dépendent.

    C'est souvent cela qui pousse à repousser à plus tard un refactoring qui finit par être évalué à une durée plus conséquente que le développement de départ, refaisant aussi passer par des phases de testing alors qu'il n'y a pas de nouvelles fonctionnalités.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  7. #27
    Membre régulier
    Profil pro
    Caissier
    Inscrit en
    décembre 2010
    Messages
    69
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Caissier

    Informations forums :
    Inscription : décembre 2010
    Messages : 69
    Points : 96
    Points
    96

    Par défaut Le chef !

    "VIte ! Tu devrais déjà avoir fini !
    Et change, ça, on n'en a plus besoin.
    Rajoute ça, c'est super important !
    Vite !"

  8. #28
    Nouveau membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    20
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 20
    Points : 26
    Points
    26

    Par défaut Contraintes matérielles et logicielles

    Négliger les contraintes matérielles et logicielles (mémoire max, par exemple).

    Ainsi, récemment, j'ai codé un élégant programme récursif de quelques lignes. Sauf que l'environnement dans lequel il tourne le fait planter lourdement au-delà de 10 niveaux de récursivité (incidemment, je ne l'avais vu nulle part dans la doc).

    Bon, ce n'était qu'un test, j'ai évidemment transformé en un code récurrent. Bonne occasion de me replonger dans mon vieux bouquin d'Arsac de 1977 qui traite de la question !

  9. #29
    Membre à l'essai
    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    octobre 2014
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Enseignant Chercheur

    Informations forums :
    Inscription : octobre 2014
    Messages : 9
    Points : 17
    Points
    17

    Par défaut

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

    l'informatique fait exception par rapport aux disciplines scientifiques : réinventez la roue à chaque fois que vous pouvez

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

    Le copier/coller fait partie intégrante de la vie d'un développeur, je veux dire au sens large, soit que l'on copie/colle réellement des bouts de code trouvé sur internet ou que l'on réutilise une librairie ou un programme.

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

    on n'aura jamais fini de réfléchir et de bien préparer l'étape de codage proprement dite. Mieux vaut parfois se lancer dedans : si on s'y lance, c'est que l'on a déjà quelques idées assez claires sur comment faire les choses.

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

    passé une certaine taille, avec des noms lisibles ou pas, un code devient de toute façon difficilement accessible, même pour vos collègues, qui ne parlent de toute façon pas le même langage que vous et n'auraient pas donné le même nom à cette variable

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

    le développement des langages de programmation va toujours dans le sens d'une densité croissante (par ex. C++, C++11, C++17) : on peut faire en quelques lignes ce qui prenait plusieurs pages auparavant.
    donc pas d'état d'âme à faire un code plus court, il faut que les lecteurs se forment aux nouvelles techniques.

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

    bien entendu, si votre compilation ou éxécution échoue sur message d'erreur, pas le choix, pour tout le reste, mieux vaut rester concentré sur le développement

    >
    > s’entêter à vouloir résoudre des problèmes sans demander de l’aide ;
    >

    c'est plus profitable (voire rentable sur moyen terme) de s'entêter à résoudre des problèmes que de demander de l'aide (rarement efficace au demeurant)

    >
    > toujours reporter la correction des bogues ;
    >

    si on reporte toujours la correction des bogues, c'est qu'il y en a trop ou que le code n'est plus maintenable, mieux vaut alors repartir "from scratch"

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

    si vous ne connaissez que le python, vous avez de quoi voir venir ...

    >
    > ignorer les forces et limites des outils que vous utilisez ;
    >

    on en fait de toute façon l'expérience

    >
    > ne pas documenter ou commenter son code ;
    >

    le strict minimum pour que, de retour de congés, vous évitiez de vous demander "mais qu'est-ce que j'ai bien pu vouloir dire ici ?"

    >
    > ignorer les tests unitaires ou les considérer comme une tâche secondaire ;
    >

    en même temps, avec un bon debogueur (gdb) et d'autres outils comme valgrind, il est possible de tester le programme complet d'un coup
    et d'éviter de ralentir le développement avec des tests partiels qui ne garantissent pas de toute façon que le tout fonctionnera bien

    >
    > ignorer les pratiques de développement éprouvées : revue de code, test-driven development (TDD), assurance qualité (QA), etc. ;
    >

    qui n'a pas franchement envie d'ignorer tout cela ?

    >
    > ne pas aimer la lecture (documentation, aide en ligne, etc.) ;
    >

    qui a envie de se palucher une montagne de doc ? qu'elle soit en ligne ou pas. Autant lire (et reprendre) le code d'un programme qui se rapproche de ce que vous voulez faire

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

    tout optimiser à la fin ? si le programme final fonctionne bien, qui osera prendre la responsabilité de le casser par des optimisations.

    quand on pense à une optimisation, mieux vaut la faire tout de suite : une semaine plus tard, c'est perdu ou vous avez d'autres problèmes sur les bras


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

    qu'est-ce que ça veut dire que maîtriser un langage de développement ? à quel niveau placez-vous la barre ?
    à moins de passer par différents projets qui vous font utiliser toutes les ressources d'un langage, il est probable que vous connaissiez encore mal les langages que vous utilisez

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

    simple ou compliqué ? cela dépend beaucoup de votre expérience, simple n'est pas nécessairement synonyme de "propre" et/ou 'maintenable', compliqué n'en n'est pas l'antonyme

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

    ne demandez jamais de l'aide, prenez carrément chez les autres ce qui vous plaît, modifiez-le à votre sauce

  10. #30
    Nouveau Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2013
    Messages : 1
    Points : 0
    Points
    0

    Par défaut

    Je souhaite rajouter une habitude qui m'a entraîné à démissionner 3 fois :
    Devoir écouter le boss qui n’a aucune compétence de développeur, qui s'en fout des cahiers des charges, t'impose des modifications incessante des projets et te met la pression pour respecter les délais.
    En gros, ma mauvaise habitude est d'être trop gentil.

  11. #31
    Membre éclairé Avatar de pcdwarf
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    février 2010
    Messages
    213
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2010
    Messages : 213
    Points : 735
    Points
    735

    Par défaut

    yannicktanguy => C'est hyperclassique.

    De façon générale il vaut mieux passer pour un emmerdeur que pour une pauvre cloche.

Discussions similaires

  1. Quelles sont les habitudes de programmation qui peuvent faire de vous un bon développeur ?
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 69
    Dernier message: 20/09/2017, 19h55
  2. Réponses: 1
    Dernier message: 07/08/2008, 10h36
  3. quelles sont les SSII qui font du forfait
    Par coax81 dans le forum SSII
    Réponses: 11
    Dernier message: 12/10/2007, 14h49
  4. Réponses: 6
    Dernier message: 03/07/2007, 10h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo