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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Qu’est-ce qui fait bon code ?

Votants
61. Vous ne pouvez pas participer à ce sondage.
  • Il doit être lisible et compréhensible

    47 77,05%
  • Il doit être fonctionnel

    45 73,77%
  • Il doit être facilement maintenable

    44 72,13%
  • Implémente des tests unitaires

    20 32,79%
  • Il doit être commenté

    20 32,79%
  • Il doit être facilement réutilisable

    24 39,34%
  • Autres (a préciser)

    7 11,48%
Sondage à choix multiple
Débats sur le développement - Le Best Of Discussion :

Qu’est-ce qu’un bon code ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    janvier 2014
    Messages
    1 039
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2014
    Messages : 1 039
    Points : 25 309
    Points
    25 309
    Par défaut Qu’est-ce qu’un bon code ?
    Qu’est-ce qu’un bon code ?
    L’entreprise IntentHQ tente d’apporter un élément de réponse

    Qu’est-ce qu’un bon code ? À maintes reprises, chacun de nous s’est déjà posé une telle question ou du moins s’est déjà vu poser cette question. Déjà en 2004, Paul Dilascia tentait de répondre à cette même question dans le magazine MSDN. Pour lui, un bon code doit fédérer 8 critères qui sont la simplicité, la lisibilité, la modularité, la séparation des différentes couches fonctionnelles, le design, l’efficacité, l’élégance et la clarté.

    L’entreprise IntentHQ qui travaille à apporter des réponses à certaines problématiques a voulu donner également un élément de réponse basé non pas sur une définition personnelle, mais plutôt sur des éléments scientifiques.

    Pour y arriver, elle a mis en œuvre une étude de janvier 2014 à janvier 2015 en interrogeant 65 développeurs directement ou par téléphone lors de plusieurs entretiens d’embauche. Les entretiens ont été effectués par la même personne et s’adressaient en général à des personnes ayant de solides compétences en java ou scala avec plus de cinq années d’expérience.

    Il faut souligner que même si les réponses peuvent varier d’un individu à un autre, nous sommes d’accord pour affirmer qu’un bon code comporte plusieurs avantages. Il permet par exemple de respecter le cahier de charges, d’éviter certaines erreurs qui rallongeraient les délais de livraison du projet et donc satisfaire ceux qui nous ont mandatés.

    Lors de cette étude, deux questions fondamentales ont été posées. À votre avis, qu’est-ce qui participe à bonifier la qualité du code ? Comment définissez-vous un bon code ?

    Les réponses à ces questions ont permis de dégager un grand nombre de réalités pouvant être regroupées sous 31 vocables. Bien qu’il soit difficile d’aborder ici tous les ingrédients de qualité relevés par l’étude, nous nous sommes focalisés sur les cinq premiers critères évoqués par les 65 développeurs interrogés. Pour chaque critère, un pourcentage a été obtenu et se présente de la manière suivante :

    En première position, nous avons la lisibilité et la compréhension. En effet, 78,46 % des personnes interrogées affirment que le code doit être lisible et compréhensible. Ce qui signifie que 8 personnes sur 10 sont d’accord sur le fait qu’un bon code doit être facile à lire et à comprendre.

    En seconde position, nous avons les tests. 29,23 % des développeurs estiment que le code doit être testé ou au moins doit supporter des tests automatisés.

    Ce même ratio suggère également que le code doit être fonctionnel.

    21,54 % estiment qu’il doit être facile d’appliquer des modifications, des corrections, des ajouts à un code sans en ressentir une perte de performance ou une dégradation de la qualité. En somme, qu’on puisse effectuer aisément la maintenance.

    En dehors de ces cinq premiers critères, nous avons entre autres, la présence des commentaires dans le code et le facteur réutilisable. Environ 11 personnes sur les 65 interrogées s’attachent à ces deux critères. Pour plus de détails sur l’ensemble de l’étude, vous pouvez vous référer au tableau suivant.


    Il faut noter qu’une corrélation forte existe entre les différents points mentionnés. Par exemple, un code simple, lisible, facile à comprendre favorisera forcément une maintenance plus aisée. À contrario, des heures seront nécessaire pour trouver des erreurs ou pour inclure de nouvelles fonctionnalités dans un code. Et cela est vrai aussi bien pour l’auteur du code que pour une tierce personne travaillant sur le code.

    C’est pourquoi IntentHQ, en se basant sur les critères les plus pertinents, c’est-à-dire les cinq premiers en raison de leur évocation par plus de 20 % des interrogés, a défini un bon code comme suit : « un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit ».

    En apportant une définition à ce concept, IntentHQ donne ainsi les normes d’un bon code. Nous espérons qu’elle fera l’unanimité et achèvera de clore le débat sur ce sujet.

    Source : Blog IntentHQ

    Et vous ?

    Que pensez-vous de cette étude?
    Etes-vous d'accord avec la définition obtenue?
    Quelle définition personnelle avez-vous d'un bon code?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Invité
    Invité(e)
    Par défaut
    J'ai envie de dire que ça dépend des besoins.

    Évidement que le code doit quand même être lisible et commenté, surtout quand on sait que quelqu'un va peut-être y jeter un œil dans 6 mois.
    Et le côté fonctionnel me parait évident. Faire un code source qui ne marche pas relève pour moi d'un non-sens.

    Par contre pour le côté test je trouve ça discutable (en même temps certaines personnes interrogées sont des devs Java). Perso quand je programme, je teste directement la fonction ou la classe. Si ça marche comme je le veux, j'intègre la prise en charge des cas problématiques, si nécessaire. Si ça ne fonctionne pas, je corrige pour que ce soit fonctionnel. Pour ce qui est de la réutilisabilité, tout dépend des besoins là encore.

    En gros le minimum vital serait :

    "un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, commenté un minimum, documenté au mieux, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit"

    Pour finir, 65 personnes qui ont des connaissance en Java OU Scala (le OU logique ^^) ce n'est pas pertinent (et les autres il n'existent pas ?).

  3. #3
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    525
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 525
    Points : 1 674
    Points
    1 674
    Par défaut
    Citation Envoyé par Gumichan01 Voir le message
    J'ai envie de dire que ça dépend des besoins.

    Évidement que le code doit quand même être lisible et commenté, surtout quand on sait que quelqu'un va peut-être y jeter un œil dans 6 mois.
    Et le côté fonctionnel me parait évident. Faire un code source qui ne marche pas relève pour moi d'un non-sens.

    Par contre pour le côté test je trouve ça discutable (en même temps certaines personnes interrogées sont des devs Java). Perso quand je programme, je teste directement la fonction ou la classe. Si ça marche comme je le veux, j'intègre la prise en charge des cas problématiques, si nécessaire. Si ça ne fonctionne pas, je corrige pour que ce soit fonctionnel. Pour ce qui est de la réutilisabilité, tout dépend des besoins là encore.

    En gros le minimum vital serait :

    "un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, commenté un minimum, documenté au mieux, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit"

    Pour finir, 65 personnes qui ont des connaissance en Java OU Scala (le OU logique ^^) ce n'est pas pertinent (et les autres il n'existent pas ?).

    Attention quand on parle de tests on ne parle pas d'une foule de tests unitaires inutiles ( genre tester qu'un entier est bien un entier...).

    je donne un exemple simple de test unitaire automatisé dans le transport :

    - Si on fait un trajet Aller-retour, alors le tarif doit être supérieur à un trajet simple.


    C'est un test logique absurde mais qui aide à la détection de non régression lorsqu'on touche à un moteur de calcul tarifaire. (Bien-sûr ce test simple est effectué pour une 100aines de situations différentes)
    Ce genre de test simple et automatisé permet de gagner énormément de temps et de proposer des logiciels stables en recette et de gérer plus simplement le changement de développeur ( qui ne connait pas forcément le métier par cœur).
    En gros on ne propose pas une recette interne lorsque ces tests échouent, cela évite de perdre du temps.

    La multiplication de ce genre de cas (qui ne changent pas avec le temps), permet une intégration plus en souplesse de nouvelles fonctionnalités. De plus avec le temps on économie énormément

    Malheureusement beaucoup d'entreprises font du test manuel ( genre QC avec tout un tas de règles chiantes à tester manuellement), 100 % de couverture n'est utile ( et rentable) que pour les cas critiques du genre lancement d'une fusée, libs utilisés par des milliers de logiciels...

  4. #4
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 328
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 328
    Points : 8 331
    Points
    8 331
    Billets dans le blog
    43
    Par défaut
    Voici ce que m'inspire le sujet ^^

    Tutoriels et FAQ TypeScript

  5. #5
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 875
    Points : 39 710
    Points
    39 710
    Par défaut
    Citation Envoyé par Olivier Famien Voir le message
    Quelle définition personnelle avez-vous d'un bon code?
    Facile : c'est du code que j'ai écrit, bien sûr . Pour tout développeur qui se respecte, le code des autres est toujours mauvais

    Parmi les critères proposés dans le sondage, j'ajouterais "bien découplé". Mais bon, ça va de pair avec la testabilité et la maintenabilité.

    Pour ce qui est des commentaires, je ne pense pas qu'ils soient indispensables en règle générale. Un bon code est généralement compréhensible juste en le lisant, il est "auto-documenté". Après il y a bien sûr des cas particuliers, par exemple un algorithme particulièrement complexe, ou un hack dégueulasse qu'on a été obligé de faire pour résoudre un problème dont l'origine est externe à notre code; dans ces cas là, les commentaires s'imposent.

  6. #6
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    525
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 525
    Points : 1 674
    Points
    1 674
    Par défaut
    Citation Envoyé par tomlev Voir le message
    Facile : c'est du code que j'ai écrit, bien sûr . Pour tout développeur qui se respecte, le code des autres est toujours mauvais

    Parmi les critères proposés dans le sondage, j'ajouterais "bien découplé". Mais bon, ça va de pair avec la testabilité et la maintenabilité.

    Pour ce qui est des commentaires, je ne pense pas qu'ils soient indispensables en règle générale. Un bon code est généralement compréhensible juste en le lisant, il est "auto-documenté". Après il y a bien sûr des cas particuliers, par exemple un algorithme particulièrement complexe, ou un hack dégueulasse qu'on a été obligé de faire pour résoudre un problème dont l'origine est externe à notre code; dans ces cas là, les commentaires s'imposent.
    Comme toujours parfaitement d'accord avec toi... ( peut être le coté fanboy .net qui me rend partial )
    En effet une méthode sans commentaires mais avec des objets/propriétés documentés et bien nommés est souvent très lisible ! De plus les IDE nous permettent de mettre un lien vers l’algorithme correspondant ( il ne sert a rien de documenter directement dans le code Dijkstra ou Levenstein si on a un lien vers une page durable, et documentée avec des schémas etc..)

  7. #7
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 677
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 973
    Points
    30 973
    Par défaut
    Citation Envoyé par Olivier Famien Voir le message
    un bon code doit fédérer 8 critères qui sont la simplicité, la lisibilité, la modularité, la séparation des différentes couches fonctionnelles, le design, l’efficacité, l’élégance et la clarté.
    100% d'accord, mais ce sont quand même des notions très subjectives. Spécialement le "design". Pourtant, il a raison, le "design" est important, dans le sens ou si il est bon, il permet de mieux appréhender le code, et il peut aussi avoir un impact sur les performances. Mais ce n'est pas quelque chose qui se décrète.

    Et c'est ce qui m'embête avec toutes ces études, ils essayent de faire croire qu'on peut tout contrôler. Le talent ne se contrôle pas. Et il est la seule source d'un design de qualité.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  8. #8
    Membre régulier
    Homme Profil pro
    Développeur Java / JEE / JavaScript
    Inscrit en
    juillet 2012
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Java / JEE / JavaScript
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2012
    Messages : 35
    Points : 73
    Points
    73
    Par défaut
    Citation Envoyé par Gumichan01 Voir le message
    En gros le minimum vital serait :

    "un bon code doit être écrit de telle sorte qu’il soit lisible, compréhensible, couvert par des tests automatisés, commenté un minimum, documenté au mieux, pas trop compliqué et effectuant parfaitement ce pour quoi il a été écrit"
    Je pense que le terme "pas trop compliqué" veut traduire la complexité du code.
    Pour moi dans un bon code c'est une fonction pour un traitement spécifique.
    Une usine à gaz dans une fonction ne peut pas être du bon code sinon ça contredit la lisibilité et la compréhension

    Pour ce qui est des tests automatisés, je ne pense pas que ça ait un rapport avec la qualité du code mais plutôt avec la maintenabilité. Tu peux faire du très beau code qui marche le jour A et le jour B tout est pété, avec les tests tu peux résoudre plus vite le problème mais en quoi ça rend ton code plus bon, c'est le test qui doit être bon !

  9. #9
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    Un bon code, c'est un code qui a été développer en pensant: "La personne qui va le maintenir est un psychopathe meurtrier qui connaît mon adresse"


  10. #10
    Membre chevronné Avatar de Jbx 2.0b
    Homme Profil pro
    Développeur C++/3D
    Inscrit en
    septembre 2002
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur C++/3D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2002
    Messages : 476
    Points : 1 868
    Points
    1 868
    Par défaut
    J'ai voté fonctionnel, mais je vois pas ce que fonctionnel vient faire ici. Comme dit Gumichan01, c'est un non sens.

    J'veux dire, le code aura beau être réutilisable, abondamment commenté, maintenable et compréhensible, si il fonctionne pas, je vois pas franchement l’intérêt.
    Et c'est pareil, je me vois mal dire à mon patron que j'ai fais X tests unitaires sur un code qui ne fonctionne pas. C'est un peu le préalable quoi.

    - Regardez monsieur le client, ce magnifique code source !
    - Et il fait quoi ?
    - Oh bah ça dépend, une fois je crois qu'on a réussit à le compiler. Certains disent même que si on le lance on peut obtenir un core dump !

    En second choix j'aurais plutôt voté pour compréhensible. C'est un peu le b.a.-ba, si le code n'est pas compréhensible, il ne vivra pas. Il sera la plupart du temps réécrit dès qu'un autre développeur devra l'améliorer. Le reste peut venir ensuite, si le composant logiciel doit être réutilisé ou rendu plus facilement maintenable, cela peut se faire éventuellement par un refactor un peu plus tard. Même si il faut avoir déjà toutes ces idées en tête dès le départ.

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Cette étude est un concentré d'évidence et on n'y apprend strictement rien de plus que sur les dizaines de milliers de blogs de développeurs...

    Je vais juste me permettre de revenir sur un aspect qui fait souvent débat : la documentation
    Oui, je suis d'accord qu'un code bien écrit avec des variables et fonctions bien nommées s'auto documentent.
    Par contre, dans certains cas, bien plus courant qu'on ne l'imagine, le doc est essentielle voir totalement indispensable : framework / API, classe utilitaire (avec vocation à être massivement réutilisées dans le programme), code des TU

    Dans le cas des framework et des API (tout comme des classes utilitaires dans les programmes), le doc est le point d'entrée des développeurs.
    Il est impensable qu'un développeur doive lire le code d'un framework pour l'utiliser (même si le code est parfaitement écrit).
    S'il y a besoin de lire autre chose que la doc pour utiliser une librairie, c'est qu'il y a un problème quelque part.

    De même pour le code des tests unitaires (TU)
    Par définition, les TU évoluent peu
    De même, une bonne documentation de ces TU permet d'évaluer rapidement la couverture fonctionnelle de ces TU.
    Ainsi, même avec du code bien écrit, devoir lire le code pour comprendre un TU me paraît totalement hors sujet
    ==> il est question du taux de couverture fonctionnelle et non du taux de couverture du code

  12. #12
    Membre actif
    Avatar de demkada
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2011
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : août 2011
    Messages : 79
    Points : 225
    Points
    225
    Billets dans le blog
    3
    Par défaut Clean code
    Dans certains de mes billets de blog, j’essaie d'apporter une réponse à "Qu’est-ce qu’un bon code ?" du point de vue d'un artisan du logiciel.
    Et ce que je ne comprend pas sur cette étude, c'est pourquoi ils ont voulu réinventer la roue et c'est un mode de fonctionnement qui est courant chez pas mal d'ingénieur et qui me semble inutile.

    Désolé pour cette introduction mais, savez-vous qu'il y a des experts de tous bords et de toutes compétences qui se sont déjà assis autour d'une table et qui ont déjà définis des indicateurs de qualité de code, tous regroupés dans une norme ISO / CEI 9126.

    Enfin, je vois que même si cette étude a su mettre en avant le développement centré sur l'humain (Facilité d'apprentissage et Maintenabilité), elle a omis plusieurs autres indicateurs, peut être moins importants dans le cycle de vie du logiciel, mais tout aussi obligatoires.

    ---------------------------------
    http://thesoftwarecraftsman.org/
    Cordialement,
    Kad D.

    _________________________________________________-
    Voter pour ce message s'il vous a aidé
    N'oublier pas le bouton si votre problème l'a été

  13. #13
    Membre expert
    Inscrit en
    juin 2009
    Messages
    1 119
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 1 119
    Points : 3 509
    Points
    3 509
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Un bon code, c'est un code qui a été développer en pensant: "La personne qui va le maintenir est un psychopathe meurtrier qui connaît mon adresse"

    Merci de citer son auteur
    Citation Envoyé par John Woods
    “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

    et quitte à choisir une citation, je citerais plutôt Knuth :
    Citation Envoyé par Donald Ervin Knuth
    “The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.”

  14. #14
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    Désolé, je ne connaissait pas l'auteur original.

    J'avais juste entendu une tel phrases lors d'une conférence (Agile Grenoble 2013), prononcé par un conférencier Belge : Pascal Van Cauwenberghe (désolé, je n'ai pas retransmis l'accent )

  15. #15
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 448
    Points
    448
    Billets dans le blog
    1
    Par défaut
    Il n'y a pas, objectivement, de "bon" code.

    Pour illustrer ma petite phrase je vous propose ce problème :
    J'aime le chocolat noir, je trouve ça bon.
    Mais ma copine trouve le chocolat noir trop amère, plus que mauvais même ! Elle préfère très largement le chocolat blanc.
    Est-ce que le chocolat noir est bon ?

  16. #16
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par Grimly Voir le message
    Il n'y a pas, objectivement, de "bon" code.

    Pour illustrer ma petite phrase je vous propose ce problème :
    J'aime le chocolat noir, je trouve ça bon.
    Mais ma copine trouve le chocolat noir trop amère, plus que mauvais même ! Elle préfère très largement le chocolat blanc.
    Est-ce que le chocolat noir est bon ?
    Tu compares des choses qui n'ont rien à voir
    D'un côté le "goût" qui est notion totalement subjective
    Et de l'autre "la qualité du code" qui est notion technique dont il existe des indicateurs pour le mesurer.
    Le débat sur le code porte sur l'importance à donner à chaque indicateur mais cela reste objectif.

    Alors que "les goûts et les couleurs"...

  17. #17
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 448
    Points
    448
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Tu compares des choses qui n'ont rien à voir
    D'un côté le "goût" qui est notion totalement subjective
    Et de l'autre "la qualité du code" qui est notion technique dont il existe des indicateurs pour le mesurer.
    Le débat sur le code porte sur l'importance à donner à chaque indicateur mais cela reste objectif.

    Alors que "les goûts et les couleurs"...
    Le code est aussi une question de goût et même de mode.

    Il y a quelques années, personne n'aurait eu l'idée de maintenir un site qui aurait une partie de javascript, toute page qui en contenait était considéré comme mal codée. La soumission de formulaires était la norme et signe de "bon code maîtrisé".
    Maintenant, une page sans javascript géré entièrement par le serveur ça fait vieux, personne n'en veux et on entends "pourquoi tu ne fais pas un $.ajax() ? C'est plus joli !".

    De même, bien documenter un code est subjectif. Si tu décris chaque partie d'un algorithme dans tes fonctions, tu fais ce qu'il faut pour une personne allergique aux documents annexes (wiki/docs), mais celui qui a plus l'habitude d'avoir sa documentation sur son deuxième écran voit ce même deuxième écran inutile et ça ne lui plait donc pas.


    Enfin, il m'arrive de réaliser du code que je trouve bon au moment où je l'écris, mais quelques mois plus tard quand je doit y replonger, je trouve que j'aurais pu largement mieux faire si j'avais fait complètement autrement. Je doute que je soit le seul dans cette situation.

  18. #18
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par Grimly Voir le message
    Le code est aussi une question de goût et même de mode.

    Il y a quelques années, personne n'aurait eu l'idée de maintenir un site qui aurait une partie de javascript, toute page qui en contenait était considéré comme mal codée. La soumission de formulaires était la norme et signe de "bon code maîtrisé".
    Maintenant, une page sans javascript géré entièrement par le serveur ça fait vieux, personne n'en veux et on entends "pourquoi tu ne fais pas un $.ajax() ? C'est plus joli !".
    Tu confonds "mode" et évolution technologique
    Le javascript a énormément évolué au cours des années et il est devenu très performant avec des framework qui permettent de mettre en place une interactivité en temps réel sur les sites web
    Cela apporte un vrai plus qu'une gestion par validation de formulaire ne permet pas
    De plus, le HTML5 a fini par normaliser et généraliser un peu tout ça

    Il y a donc une évolution des technologies et une évolution des pratiques.
    Par contre, les critères d'évaluation d'un code "bien écrit" reste les mêmes.

    Pour ce qui est de la documentation du code : il y a débat et il ne date pas d'hier
    Sur ce point là, c'est bien une constante

  19. #19
    Nouveau membre du Club Avatar de bach58
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations forums :
    Inscription : septembre 2007
    Messages : 35
    Points : 29
    Points
    29
    Par défaut
    Il serait peut-être intéressant de commencer par définir ce qu'est un "code"!

    Un code en Fortran, ne recouvre pas la même signification qu'en APL ou en Java, et par là ne peut être jugé de la même manière.

    Prenons "la lisibilité", qualité indispensable pour la maintenance et l'évolution. Dépend-elle du code toujours?
    En Java, C++ & Co, la première qualité d'"un code" est celui de la structure de classes. Or celle-ci est illisible dans un code Java! Il vaut mieux avoir un dessin à côté pour la comprendre.

    De même, si "le code" implémente une méthode complexe, avec des niveaux d'abstraction assez poussés, il ne sert à rien de lire le code, avant de comprendre parfaitement cette méthode!

    Bref, juger de la qualité d'un programme dépend de bien de paramètres qui dépassent le "code" lui-même.

  20. #20
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    juillet 2010
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : juillet 2010
    Messages : 422
    Points : 1 057
    Points
    1 057
    Billets dans le blog
    1
    Par défaut
    Lisibilité
    Facilité de maintenance
    Bien commenté (au cas où on jettera un coup d' oeil dans 2,3 ou 6 mois par exemple)

Discussions similaires

  1. Réponses: 5
    Dernier message: 08/03/2011, 16h26
  2. Comment récupérer le bon Code Erreur par le tray-catch
    Par belaggoun2000 dans le forum C++Builder
    Réponses: 1
    Dernier message: 16/02/2009, 15h03
  3. [cue] Qu’est-ce qu’un fichier cue ?
    Par Furius dans le forum Autres Logiciels
    Réponses: 6
    Dernier message: 05/01/2006, 16h59
  4. [.sit.hqx] Qu’est-ce qu’un fichier .sit ?
    Par Furius dans le forum Autres Logiciels
    Réponses: 4
    Dernier message: 01/01/2006, 17h24
  5. [Sécurité] Ecrire du bon code PHP
    Par LordBob dans le forum Langage
    Réponses: 15
    Dernier message: 17/11/2005, 23h51

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