Discussion :

[Olivier Famien]

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?

[Invité]

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

[dfiad77pro]

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

[yahiko]

Voici ce que m'inspire le sujet ^^

[tomlev]

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.

[dfiad77pro]

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

[el_slapper]

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

[Greg-dev]

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 !

[Laurent 1973]

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"

[Jbx 2.0b]

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.

[Saverok]

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

[demkada]

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/

[AoCannaille]

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

“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 :

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

[Laurent 1973]

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 )

[Grimly]

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 ?

[Saverok]

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

[Grimly]

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.

[Saverok]

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

[bach58]

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.

[landry161]

Lisibilité
Facilité de maintenance
Bien commenté (au cas où on jettera un coup d' oeil dans 2,3 ou 6 mois par exemple)