Discussion :

[Mat.M]

@mathieu :

je te re-post un lien que j'ai déjà posté plusieurs fois :

Rewrites Considered Harmful?
en particulier sa conclusion :

A suggestion: If you have a very successful application, don't look at all that old, messy code as being "stale". Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.

oui parfaitement d'accord ; c'est une règle universelle : quelque chose qui fonctionne bien , un méchanisme, un logiciel on n'y touche pas..
mais le problème c'est comment faire pour ajouter des nouvelles fonctionnalités à un projet informatique très mal conçu au départ ?

Donc eh ben on risque de faire comme les Shadocks qui pompent éternellement et le projet informatique c'est un truc sans fin
Sinon dans la mythologie ça s'appelle le Mythe de Sisyphe
Remarque : le bon côté des choses c'est que ça donne du travail aux programmeurs

[Matthieu Vergne]

@Matthieu Vergne : je veux voir le code d'une application complète sans aucun commentaire qui soit parfaitement compréhensible rien que grâce au génie du génie (non ce n'est pas une répétition) qui a écrit le code. Le code complet + les docs nécessaires pour le comprendre (il y en a forcément si l'appli fait des choses non triviales). D'ailleurs il me semble qu'on ne peut en fait pas éviter d'ajouter des commentaires dans le code faisant le lien entre la doc extérieure au code et le code lui-même. Dur de mettre toutes les infos utiles pour cela dans le code à propremet parler, même si l'on est un génie, donc un peu de commentaire ne ferait pas de mal, si ?

Je rappelle que quand on parle de commentaires on ne parle pas de documentation style Javadoc. La documentation est évidemment indispensable, que ce soit pour faire le lien avec la doc externe (e.g. CdC, bugtracker) ou tout simplement pour décrire l'algorithme utilisé (ou au moins donner son nom et mettre un lien si on l'a choppé sur le net). On parle bien de commentaires qui visent à décrire des lignes de code. Autrement dit redire en langage naturel ce que fait le code.

Vu ta réponse on dirait que tu interprète mes messages comme "à part le code, y'a rien d'autre", mais non. Je sais on fait vite l'amalgame mais on l'a déjà précisé koala et moi. On fait la différence entre :
- de la documentation (entêtes de fonctions/classes visant à donner une description générale de l'élément et de son utilisation, ses entrées/sorties, etc.)
- des commentaires de tutos (code ultra-commenté visant à expliquer chaque ligne de code)
- des commentaires de prod

Les deux derniers sont le même style de commentaire (à l'intérieur d'une fonction), mais le premier dans un contexte d'apprentissage, où il est donc nécessaire de tout décrire car ça s'adresse à des néophytes, et le second dans un contexte de prod donc qui s'adresse à des gens qui connaissent le domaine et le langage (mais pas forcément le programme).

Dans le sens "documentation" : demander si les commentaires sont nécessaire si le code est bien écrit n'a pas de sens, car la doc a aussi pour vocation à être extraite et organisée en dehors du code. Que le code soit bien écrit ou non, si on n'a pas cette documentation ça va pas se générer tout seul. C'est typiquement là qu'on va y renseigner les besoins à satisfaire ou faire le lien avec le CdC si il y en a un. Donc la qualité du code n'a rien à voir, la doc a sa propre valeur à elle seule. On peut nommer correctement une fonction mais ça ne va pas nous dire comment l'utiliser (bien qu'une fonction simple et bien nommée avec des arguments communs n'a généralement pas besoin de doc, style setX(), getX(), add(), etc.).

Dans le sens "commentaires de tutos" : ça n'a pas de sens non plus, vu que les commentaires font partie intégrante du tuto. C'est presque plus important que le code autour. Un code non commenté pour un néophyte n'a tout simplement pas de sens, vu qu'il est justement là pour apprendre le langage.

Il n'y a que dans le dernier cas que la question a vraiment du sens. Et dans ce cas précis ma réponse est celle que tu connais.

[clementmarcotte]

Bonjour,

Je n'ai pas lu les 400+ autres réponses, mais je pense que l'ajout, ou non, de commentaires doit être décidé au cas par cas, selon le gros bon sens.

J'ai la nette impression que mes lecteurs anglophones ont apprécié mes commentaires en anglais.

En passant, si les responsables de Developpez.com souhaitent mettre une version française ici, je suis tout à fait disposé à la faire.

La source est déjà disponible ici.

[souviron34]

mais le problème c'est comment faire pour ajouter des nouvelles fonctionnalités à un projet informatique très mal conçu au départ ?

Je ne vois pas le rapport avec les commentaires ou pas...

[moldavi]

Re.

Sur la même idée, un code dont tu ne connais même pas la théorie qu'il tente d'implémenter n'a pas vocation à être compris.

Oui. Ceci est valable, si le code n'a aucun bug. Mais si le code est buggé...

Si le code est buggé, il faudra s'approprier le code, comprendre le code et la théorie, et enfin trouver l'erreur. Il faudra refaire le cheminement intellectuel du précédent développeur, le cheminement intellectuel de son programme et aller lire la documentation de (50) pages sur la théorie. Ses commentaires ne pourront jamais remplacer tout cela.

Pour corriger un bug qui implémente incorrectement une théorie, il faudra comprendre cette théorie. Pour corriger le bug, il faudra scruter le code à la moindre ligne...

Bref je ne vois pas le gain de temps entre commentaire et efficacité de correction de bug.

Je préfère passer plus de temps à rendre mon code stable et sans bug, plutôt qu'à le commenter. Avec un peu de chance, personne n'aura à le débugger... Et personne n'aura à finir le travail que j'aurai mal fait.

PS: je ne suis pas contre les commentaires. Je suis juste mitigé selon les situations.

Je pense toujours que c'est au choix du développeur d'appliquer tel concept selon telle situation.

Nous ne travaillons pas tous et toujours dans les mêmes situations. Nous faisons part de nos points de vue, afin de permettre à d'autres développeurs de prendre une décision.

PS2: donc ne pensez-pas que j'ai une vue à géométrie invariable. Je ne fais part que de mon expérience personnelle.

[Matthieu Vergne]

Si tu as des tests unitaires que tu peux utiliser comme filet de sécurité ou pour te montrer ce qui bug, tu n'es pas obligé de maitriser toute la théorie non plus. Si c'est bien découpé, ça se limite à comprendre la fonction concernée, qui peut être relativement simple malgré toute la complexité sous-jacente. Évidemment en connaitre plus est toujours mieux, des fois que tu ais plusieurs façon de corriger et qu'il y en ai certaines plus adaptées au contexte.

C'est aussi comme ça que tu peux distribuer le travail. En ayant des parties indépendantes qui ne nécessitent pas de connaitre tout le reste. Sinon des applications comme des ERP ne seraient tout simplement pas faisables. Trop de domaines différents dans une même application.

[koala01]

Re.



Oui. Ceci est valable, si le code n'a aucun bug. Mais si le code est buggé...

S'il est buggé, tous les commentaires du monde ne t'aideront pas à trouver la raison si tu ne connais pas la théorie qui se rapporte au code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Si le code est buggé, il faudra s'approprier le code, comprendre le code et la théorie, et enfin trouver l'erreur. Il faudra refaire le cheminement intellectuel du précédent développeur, le cheminement intellectuel de son programme et aller lire la documentation de (50) pages sur la théorie. Ses commentaires ne pourront jamais remplacer tout cela.

Et le meilleur moyen, le moyen le plus pérenne en tout cas, passe par le code, pas par les commentaires

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Pour corriger un bug qui implémente incorrectement une théorie, il faudra comprendre cette théorie. Pour corriger le bug, il faudra scruter le code à la moindre ligne...

la moindre ligne significative dans la génération du code binaire, oui...

Les commentaires, bons ou mauvais, ne changeront rien (pire, les mauvais commentaires ou les commentaires obsolètes risquent surtout d'induire le lecteur en erreur )

PS: je ne suis pas contre les commentaires. Je suis juste mitigé selon les situations.

Contrairement à ce que mes interventions pourraient laisser croire, je ne suis pas totalement contre les commentaires.

Tout ce que je demande, c'est qu'ils ne paraphrasent pas le code et qu'ils apportent réellement un plus dans la compréhension du code.

De nombreux commentaires ne respectent pas ces deux lignes directrices, ce qui les rend au mieux inutiles, au pire dangereux

[el_slapper]

(.../...)

Dans le second cas tu as les spec, ce qui est bien, mais en général les spec restent à un certain niveau et ne descendent pas jusqu'au niveau nécessaire pour les traduire directement en code. Il y a donc des choix d'implémentation à faire. Et dans l'ancien code ces choix ont été faits, mais si tu n'as rien pour te dire comment ont été fait ces choix tu risque effectivement de repasser par les même bugs.

J'avais aussi l'avantage de connaitre l'ancien code du deuxième cas comme ma poche, même si je ne l'avais pas écrit. Un test massif sur une volumétrie mensuelle de prod, y'a que ça de vrai pour trouver tout ce qui ne va pas.

Au passage, le commentaire que tu donnes est typiquement le genre de chose que j'imagine avoir dans un algo optimisé, qui vise donc à exploiter les spécificités du système pour être mieux (que ce soit en vitesse, mémoire ou que sais-je). C'est le seul cas où j'admets qu'il soit nécessaire d'avoir des commentaires (tout peut toujours être utile, mais pas nécessaire, la question elle est là).

Non. Je crois que tu ne parviens pas à comprendre ce que c'est que du code très ancien. La plupart des éléments ne permettent même pas de savoir à quoi ça sert. Je ne parle même pas de "comment ça marche". Juste, "à quoi ça sert".

Si tu ne respectes pas cette condition, donc soit tu fait une conception à l'arrache (ou juste incomplète) soit tu considères une classe d'utilisations différente, alors oui tu auras besoin de commentaires pour bien faire comprendre que ton code fait ce qu'il est censé faire. Le premier cas, c'est le plus courant : qui fait l'effort nécessaire pour avoir une conception intégrale avant de coder ? Tellement peu de monde. Pourtant ça existe : des algos bien connus, même complexes, on n'a qu'à les récupérer sur le net, sous forme de pseudo code. Il ne reste qu'à corriger les erreurs dus au changement de langage. C'est ce que je fais et ça n'a jamais loupé. Quand j'implémente un algo ça marche généralement du premier coup (je dis généralement pour rester ouvert, mais je ne me rappelle pas de cas qui aient foiré). Et là où je choppe l'algo, il y a généralement des examples parce que c'est du wikipédia ou un tuto sur le sujet, du coup je fais des tests automatisés sur ces exemples, et ça passe généralement vert dès le départ (cela dit j'ai déjà eu du rouge, mais à cause d'une erreur dans l'exemple).

Tu est vraiment focalisé sur des trucs standards. Un algo qui calcule la taxe d'assurance en fonction de l'ancienneté du produit assurance auto, ça ne se trouve pas sur le web.

(.../...)Néanmoins, cela n'est vrai que si effectivement tu considères des algos plus génériques que nécessaires à la conception et tente de les optimiser à l'implémentation. J'imagine déjà koala01 répondre que si tu sais que c'est toujours le cas tu peux intégrer ça directement dans ta conception et du coup les commentaires deviennent inutiles. Je suis bien d'accord. Mais pour ceux qui veulent profiter d'une conception déjà faite et robuste (donc on exploite l'expérience passée, on ne la perd pas) on peut tomber sur ce genre de cas. Et pour moi c'est le seul pour lequel il soit nécessaire d'avoir des commentaires malgré que le code soit bien écrit (pour rappel, tous les autres cas mènent à un code mal écrit car ne correspondant pas à la conception, alors qu'ici ça correspond car le contrat est respecté).

en bref, tu ne sais pas ce que c'est que du code fonctionnel spécifique. Pour des trucs standards, ta théorie marche peut-être. Mais les astuces, elles sont loin de se limiter à la performance.

Mais encore une fois, je le précise, le but n'est pas de dire "ce code existant est mal écrit donc faut taper sur celui qui l'a fait" mais "si je veux avoir un code bien écrit dès maintenant il y a des astuces que je peux appliquer". Le but n'est pas de justifier ou non le bien fondé d'un code déjà mal (ou bien) écrit. Et encore moins de définir la "bonne écriture" sur une pratique moyenne. Toute remarque visant donc à parler d'un cas particulier qu'il aurait vécu n'a aucun intérêt pour attester de la nécessité des commentaires. L'utilité se définit sur le cas particulier, mais la nécessité sur l'ensemble des cas. Pour les plus matheux, il est suffisant mais pas nécessaire d'avoir des commentaires si on a un code bien écrit.

Ben oui, mais un code est écrit pour être lu, aussi. Et pas forcément seulement par des clones de John Carmack. Tout ça, c'est une théorie élitiste qui empêche la maintenabilité du code.

[koala01]

Non. Je crois que tu ne parviens pas à comprendre ce que c'est que du code très ancien. La plupart des éléments ne permettent même pas de savoir à quoi ça sert. Je ne parle même pas de "comment ça marche". Juste, "à quoi ça sert".

J'ai envie de poser la question qui fâche : pourquoi selon toi
a- parce que les noms de variables, de fonction(nalité)s, de structures étaient vraiement mal choisis
b- parce que certains tronçons de code faisaient le café, la vaisselle et la lessive
c- parce qu'il n'y avait aucun cartouche pour le dire
d- un peu de tout cela

Tu est vraiment focalisé sur des trucs standards. Un algo qui calcule la taxe d'assurance en fonction de l'ancienneté du produit assurance auto, ça ne se trouve pas sur le web.

Non, mais s'il ne se trouve pas sur le web, la personne qui aura demandé de l'implémenter doit l'avoir donner quelque part, non

en bref, tu ne sais pas ce que c'est que du code fonctionnel spécifique. Pour des trucs standards, ta théorie marche peut-être. Mais les astuces, elles sont loin de se limiter à la performance.

Mais combien d'astuces ne sont-elles pas utilisées plus pour obfusquer un peu le code que pour autre chose

• Il y a des astuces qui permettent d'optimiser l'utilisation de la mémoire et donc la mise en cache, comme celle qui consiste à organiser les membres d'une structure selon leurs tailles respectives (du plus grand au plus petit) pour éviter l'effet de "padding".
• Il y a des astuces qui permettent d'éviter de traiter une série de valeurs lorsqu'on sait que ce n'est pas utile
• Il y a quelques astuces qui permettent éventuellement de gagner "quelques cycles" processeur lors de l'exécution (micro optimisation)
• Il y a quelques astuces qui permettent de "simuler" des comportements de plus haut niveau (ex : pour simuler les fonctions virtuelles dans un langage non orienté objets)
• Il y a d'autres astuces auxquelles je ne pense pas forcément ici, mais qui ont des objectifs bien particulier

Le fait d'utiliser ce genre d'astuces, bien qu'il faille toujours prouver (pour certaines du moins) que l'on gagne effectivement en efficacité sont en théorie connues par ceux qui prétendent connaitre le langage avec lequel ils travaillent.

Mais, si une astuce ne fait pas partie de ces possibilités, quel intérêt présente-t-elle, hormis celui de rendre celui qui a écrit le code "indispensable"

Dés lors, la question devient : aurait on pu se passer de cette astuce et de la nécessité du commentaire qui va avec

Ben oui, mais un code est écrit pour être lu, aussi. Et pas forcément seulement par des clones de John Carmack. Tout ça, c'est une théorie élitiste qui empêche la maintenabilité du code.

Le code est destiné à être lu, oui, et par des gens dont l'employeur est au minimum en droit d'espérer qu'ils connaitront un tout petit peu le langage avec lequel ils travaillent.

Mais encore une fois, si un code utilise (essentiellement) des noms cohérents dans le cadre du contexte envisagé, il devrait se suffire à lui-même dés le moment où tu as juste la prétention de connaitre le langage que tu utilises.

Bien sur, on peut parler de langage comme perl, qui est un langage très efficace (de ce que j'en ai entendu) mais qui rend les choses, même les plus simples, particulièrement difficiles à lire (ou les langages fonctionnels auxquels j'ai énormément de mal à me faire).

Je m'y ferai très certainement si je dois absolument travailler avec, mais, en attendant, je ne prétends en tout pas les connaitre

[el_slapper]

J'ai envie de poser la question qui fâche : pourquoi selon toi
a- parce que les noms de variables, de fonction(nalité)s, de structures étaient vraiement mal choisis
b- parce que certains tronçons de code faisaient le café, la vaisselle et la lessive
c- parce qu'il n'y avait aucun cartouche pour le dire
d- un peu de tout cela
Non, mais s'il ne se trouve pas sur le web, la personne qui aura demandé de l'implémenter doit l'avoir donner quelque part, non
Mais combien d'astuces ne sont-elles pas utilisées plus pour obfusquer un peu le code que pour autre chose

Le point a et c sont interessants. Il y a certainement des progrès à faire à ce sujet. Mais je ne crois pas que ça permette d'éliminer les commentaires pour autant. Le point B est plus vicelard : quand un code à 36 ans d'âge, ça devient difficille à éviter.

(.../...)Le fait d'utiliser ce genre d'astuces, bien qu'il faille toujours prouver (pour certaines du moins) que l'on gagne effectivement en efficacité sont en théorie connues par ceux qui prétendent connaitre le langage avec lequel ils travaillent.

Je parle fonctionnel, on me répond technique. Exemple d'astuce fonctionelle : on sait si le compte bancaire concerne un employé de la banque en regardant le 17ème chiffre de son numéro de compte(chez une banque précise, ça ne marche pas pour la concurrence).

Typiquement le genre de truc qui peut rendre chèvre le pauvre malheureux qui récupère le code - quand ça n'est pas commenté.

Mais encore une fois, si un code utilise (essentiellement) des noms cohérents dans le cadre du contexte envisagé, il devrait se suffire à lui-même dés le moment où tu as juste la prétention de connaitre le langage que tu utilises.(.../...)

Foutaises. Juste, foutaises. Ca peut être vrai sur du code récent. Mais au bout de décénnies? Non, foutaises et illusions.

Tapes-toi des vieux nanards de 36 ans d'âge. Sur lesquels des dizaines de mainteneurs différents sont passés. Souvent en urgence(du genre, il reste deux heures pour corriger, sinon 100,000 avis d'échéance auront un montant faux à payer par le client. Vécu). Souvent en passage d'équipe sans passation de connaissances. Et tu comprendras pourquoi tes belles théories ne tiennent pas.

On dirait que tu codes un truc pour un seul repreneur, et puis basta. Que toujours les passations se passeront bien. Que toujours des gens compétents repasseront dessus. Que toujours ils auront le temps de faire les choses bien.

Dans la vraie vie, ça n'existe pas - ou alors pas longtemps.

[souviron34]

D'ailleurs, outre ce que dit el_slapper avec qui je suis 100% d'accord, j'ajouterais un ou 2 trucs..

Mais combien d'astuces ne sont-elles pas utilisées plus pour obfusquer un peu le code que pour autre chose

Dans la vraie vie ??? aucune...

A moins que ça devienne un mouvement dans vos générations, mais la conscience professionnelle de chacun fait que de ma vie, je n'ai strictement jamais vu ce cas...


Nous sommes des pros, hein, pas des gamins qui veulent jouer à qui a la plus grosse...

• Il y a d'autres astuces auxquelles je ne pense pas forcément ici, mais qui ont des objectifs bien particulier

Le fait d'utiliser ce genre d'astuces, bien qu'il faille toujours prouver (pour certaines du moins) que l'on gagne effectivement en efficacité sont en théorie connues par ceux qui prétendent connaitre le langage avec lequel ils travaillent.

Mais, si une astuce ne fait pas partie de ces possibilités, quel intérêt présente-t-elle, hormis celui de rendre celui qui a écrit le code "indispensable"

Alors ta conclusion est essentiellement celle de quelqu'un qui n'a pas eu réellement une grande expérience du style d'astuces qu'on peut trouver : ça peut être pour ré-utiliser du code dans un contexte différent, pour en faire quelque chose comme une routine de bibliothèque, ça peut être à cause d'un réglement (éventuellement ponctuel), ça peut être pour une raison de "ça marche comme ça et pas autrement", ...(ne serait-ce que la valeur numérique d'un coefficient, qui peut n'avoir strictement aucune autre justification que "c'est avec ça que ça marche")

Vous avez essentiellement une vue "carrée", basée sur une perception théorique.. et liée à quelque chose qui serait "temps réel", c'est à dire sans contraintes de superpositions de choses différentes.

La pratique, elle, est remplie de choses étranges, pas forcément super-directes à comprende, même par quelqu'un maîtrisant parfaitement le langage

(j'ai par exemple fait en C une partie d'un module comportant des quintuples pointeurs *****tab et des listes chaînées de triples pointeurs : quelque peu opaque à comprendre même pour un expert, si on ne met pas quelques lignes de commentaires à chaque fonction en plus de le faire en tête du module, et en plus d'une doc à part : mais c'était le seul moyen pour avoir un découpage "objet" prenant en compte tous les cas de figure que je pouvais avoir y compris celui qui posait problème à tout le monde, tout en optimisant l'utilisation mémoire)

Le code est destiné à être lu, oui, et par des gens dont l'employeur est au minimum en droit d'espérer qu'ils connaitront un tout petit peu le langage avec lequel ils travaillent.

Voir plus haut..

Dans certains cas, on a beau être expert, on sèche - ou en tous cas on va mettre un sacré bout de temps - à déchiffrer, si on n'a pas de commentaires...(en ce qui concerne les astuces.. mais en ce qui concerne par exemple des tests ou des valeurs numériques, ça sera à comprendre, et pas à déchiffrer, qu'on aura du mal).. Et même en ayant l'explication ET en étant expert on va mettre du temps... Alors sans explications c'est à s'arracher les cheveux...


Prenons le cas d'un réglement qui se voit modifier temporaitement, exceptionellement, pour une période de 6 mois.... Mais qui bien entendu ne s'applique pas "en temps réel", mais pour une période déterminée..

Si ton logiciel doit pouvoir permettre de calculer quelque chose, avant , ou pendant, ou après cette période, tu as possiblement 3 cas... Et ça c'est jste pour un seul réglement une seule fois..

Ou pour de la rétro-compatibilité...

Mais sinon, ça peut aussi être pour faire référence à un numéro de bug report... Auquel on devra se reporter pour avoir l'explication...


En gros, les commentaires sont essentiels, dans la vraie vie... Vos visions, à toi et Mathieu, sont des visions de théoriciens.. : la différence entre la théorie et la pratique, c'est qu'en théorie il n'y en a pas...

[Matthieu Vergne]

En attendant, tout ce que vous donnez comme argument pour nous contredire sont des exemples où la propreté du code passe après tout le reste, justement parce qu'on a autre chose à faire que de passer du temps dessus.

On est parfaitement conscient de ce qui se passe en pratique, mais la vraie différence entre vous et nous est que nous on ne fait pas passer un code fait "sous contraintes incompatibles avec la recherche de qualité" pour un code bien écrit. Nous on se fait une idée de ce qu'est un code bien écrit et quand on en a l'occasion on se donne les moyens de l'appliquer. Vous vous dites ce qui se fait en pratique et limitez les objectifs à ces cas. C'est certes plus réaliste, mais clairement moins gratifiant et motivant.

Quand on veut obtenir quelque chose il faut viser plus haut pour obtenir au moins ce qu'on veut. L'idée est la même ici. Même si on n'arrive pas toujours à avoir un code bien écrit à 100%, car nous aussi on sait ce qu'est la pratique, au moins on sait ce qu'on vise et on s'en rapproche autant qu'on peut, et surtout on ne va pas faire passer un code fait à la va vite mais ultra commenté pour un code bien écrit.

La question en elle-même est polémique parce que "bien écrit" est ambigüe. Tant qu'il n'y aura pas une définition exacte de cette notion on pourra encore discuter longtemps. De notre point de vue à koala01 et moi, un code bien écrit est un code qui se suffit à lui-même dès lors qu'on connait le langage. De la même manière qu'un document est bien écrit quand il se suffit à lui-même quand on connait la langue (self-contained en anglais). Cependant, avec ce point de vue, il est clair qu'un parfait néophyte sur le sujet n'a pas vocation à comprendre. S'il faut initier quelqu'un au contexte implémenté/décrit dans le code/document, il y a des tutos/cours/articles à visée pédagogique pour ça. Le code/document construit par dessus cette couche pour apporter ses propres éléments et n'a pas vocation à refaire toutes les bases, ce n'est pas son boulot.

De notre point de vue, un code commenté (pas documenté hein, on parle bien de commentaires qui décrivent les lignes de code) est comme un document qui est annoté de partout pour expliquer les tournures de phrases utilisées et ambigüités. Est-ce qu'on appellerai un tel document un "document bien écrit" ? Je ne pense pas. Et dans cette même optique un code bien écrit n'est pas, pour nous, un code commenté.

Question pratique, c'est la même chose : parce qu'on n'a pas le temps on va écrire un document à la va vite en se focalisant sur le contenu plutôt que sur la forme et les gens qui devront le lire nous poserons des questions parce qu'ils auront pas compris telle ou telle partie, ou feront tout simplement des bêtises parce qu'ils n'auront pas cherché plus loin. La pratique elle est là. Est-ce que ça veut dire pour autant qu'on doit accepter de dire que c'est un niveau suffisant pour dire ce qu'est un document bien écrit ? Nous on dit non. Libre à d'autres de dire oui.

Libre à vous de ne pas être d'accord, mais pas de faire passer nos points de vue pour des gamineries sans fondements solides. Quand on en vient à parler de nécessité et non d'utilité, il convient de comparer l'ensemble des points de vus, et il y a des cas où on peut raisonnablement dire que les commentaires sont inutiles parce que le code est suffisamment bien écrit pour pouvoir s'en passer. Dès lors on ne peut plus dire qu'il est nécessaire de commenter son code. Si on veut parler d'utilité il suffit de montrer un cas où on ne peut pas faire sans commentaires, et les exemples que vous donnez vont dans ce sens. Dès lors on ne peut pas dire que les commentaires sont inutiles. Et ça vous l'avez très bien montré et on n'a jamais dit le contraire. Ce n'est juste pas la question.

Et pour ceux qui se sentiraient froissés par cette conclusion comme quoi que s'ils mettent des commentaires c'est probablement qu'ils ont un code encore mal écrit, qu'ils se calment : tout le monde passe par là et rarement en sort, même les meilleurs analystes-programmeurs. Un code bien écrit est un gage de qualité, mais comme tout objectif de qualité ça passe après le reste dans la pratique. On a tous des contraintes à tenir qui font qu'on aura rarement l'occasion d'avoir un code bien écrit. Mais ne pas être capable d'obtenir un idéal (qui n'est pas une utopie quand même) ne doit pas pour autant faire revoir à la baisse vos propres objectifs.

Si vous pensez qu'un code bien écrit est plein de commentaires alors mettez-en. Personnellement je suis passé par là et la pratique m'a fait comprendre que des commentaires clairs et concis pouvaient avantageusement être remplacés par du code équivalent. Je l'applique autant que je peux et j'ai bien moins de débogage à faire et le peu que j'ai est bien plus rapide à régler, ce qui me laisse tout le temps nécessaire pour raffiner d'avantage pour écrire mieux et améliorer ainsi que faire les tests qui feront le filet de sécurité pour les futurs programmeurs. Si pour vous ça marche différemment alors faites différemment, mais ça ne remet pas pour autant en cause l'efficacité de nos méthodes et des conclusions qui vont avec.

[CodeurPlusPlus]

99% du temps, la qualité de mon code (qui implique une grande lisibilité entre autres) est ma première préoccupation quand je programme. Je n'ai pas d'impératif de délai et mes besoins en terme de performance, s'ils nécessitent des algos optimisés, peuvent se passer de micro-optimisation. Donc je peux passer autant de temps que je veux pour rendre le code le plus maintenable possible. C'est précisément dans ce contexte que je trouve que certains types de commentaires me sont indispensables. Etrange non ? La prétention de koala1 et la tienne consistent à penser que vous faites plus lisible que moi, plus lisible à vos yeux comme aux yeux de n'importe qui de raisonnable, en vous passant de certains commentaires que je trouve indispensables. C'est vraiment de la prétention, et rien d'autre, de votre part, c'est tout !
Mais juste après mes études, je tenais le même genre de discours, alors votre argumentaire je le connais.

Vous n'avez jamais travaillé sur un logiciel vieux de quelques décennies, ni dans des équipes réunissant des gens de générations différentes et d'horizons très variés. Ecoutez el_slapper et Souviron34 qui montrent souvent la voie de la sagesse dans les discussions de ce type

Votre vision de choses ne doit fonctionner qu'entre informaticiens formés dans la même décennie, sur les mêmes types de langages, n'ayant pas encore vu de vrai gros projet... et encore, en pratique ça ne va vraiment marcher que quelques années tout au plus, si vous avez de la chance... mais bon sang, quelle est cette étrange maladie qui vous pousse à croire que les personnes qui liront votre code seront des mutants télépathes capables de lire dans vos pensées ? L'inexpérience sans doute ! Chaque programmeur a un style, qui change avec le temps pour rendre les choses encore plus compliquées. Deux personnes avec autant d'expérience et la même connaissance précise du langage utilisé écriront la même application d'une manière totalement différente, même si on leur fait respecter les mêmes conventions de codage. Donc il faut au moins être télépathe pour trouver que les commentaires ne sont pas nécessaires. "Ok, je mets une heure pour comprendre ce que je comprendrais en trois minutes, mais au moins c'est du code sans commentaire, homologué par Matthieu Vergne !"

Quelle est cette maladie qui vous fait penser qu'un ancien code qui serait devenu "illisible" ou illisible (avec ou sans guillemets selon le niveau de bonne ou de mauvaise foi qu'y met celui qui reprend le code) l'est forcément devenu parce que ses auteurs originels étaient incompétents ? L'arrogance sans doute ! En trente ans les habitudes changent même dans les très grandes lignes, et parfois c'est uniquement pour cela qu'un vieux programme est dur à reprendre.

Dans votre théorie à vous, vous prenez beaucoup trop de "si" comme acquis. Vous supposez que le programmeur qui reprend le code sait ceci ou cela, connait ceci ou cela, et donc ne devrait pas avoir besoin des bons commentaires que les bons programmeurs n'arrivent pas à supprimer. Mais ce ne sont que des suppositions. Elles ne resteront pas vraies en tout lieu et en tout temps, si toutefois elles ont déjà été vraies ailleurs que dans vos têtes ou dans vos formations universitaires dont on ne sait jamais si par hasard elles n'auraient pas, d'universitaire, plus que le nom... mais c'est un autre sujet.

Je pense que vous n'avez pas encore suffisamment galéré (prenez ce terme comme bon vous semblera) pour comprendre que la prudence que prônent vos adversaires dans ce topic est une nécessité. Elle va d'ailleurs évidemment bien plus loin que le débat "commentaires ou non"... mais bon, hein, et alors, et même si, et puis zut, c'est pas des programmeurs niouscoules qui vont m'apprendre à coder quand même.

[CodeurPlusPlus]

un code bien écrit est un code qui se suffit à lui-même dès lors qu'on connait le langage.

Donc, si on te donne un code écrit dans un langage que tu connais bien, avec ou sans commentaires, et si tu n'arrives pas à le comprendre facilement, alors c'est que le code est mal écrit.

Bravo. Avec des raisonnements pareils on n'arrive à trouver bien écrit que ce que l'on a écrit soi-même. Donc le code que tu fais et qui te satisfait tout à fait même sans commentaire, un autre programmeur qui pense comme toi le trouvera parfaitement infect, comme toi tu trouveras le sien infect. Dur de travailler en équipe à ce moment-là.

Quand tu atteins un certain niveau de qualité dans ton code, et quand tu dois comprendre du code écrit par un informaticien du même niveau, en général ça paraît toujours illisible au premier abord. Il faut du temps pour comprendre les vrais défauts du code des autres (souvent moins grands et moins nombreux que le laisse penser la première impression qu'on a) et encore plus de temps parfois pour en comprendre les vraies qualités.

Bénis soient ceux dont les commentaires aident les autres à comprendre leur style. A bas ceux qui se croient suffisamment géniaux pour ne pas avoir besoin de commenter.

[CodeurPlusPlus]

on parle bien de commentaires qui décrivent les lignes de code

Cela dépend de ce qu'on entend par "décrire". Les commentaires qui paraphrasent le code sont tout à fait inutiles, personne n'a dit le contraire.

Si vous pensez qu'un code bien écrit est plein de commentaires alors mettez-en. Personnellement je suis passé par là et la pratique m'a fait comprendre que des commentaires clairs et concis pouvaient avantageusement être remplacés par du code équivalent.

Un jour tu t'es rendu compte que tu écrivais plein de commentaires qui pouvaient être avantageusement supprimés à condition de mieux écrire le code. Et tu l'as fait. Et tu as suite à cela pu supprimer beaucoup de commentaires.

C'est bien. Nous sommes tous passés par là.

Maintenant il ne faudrait pas que tu croies qu'il y a d'un côté les cadors qui sont passés par là (cadors dont tu ferais partie) et d'un autre côté les ânes qui n'ont pas connu cette phase et qui passent donc leur temps à plomber leur code de commentaires non nécessaires.

A part quelques débiles qui ne sauront jamais coder correctement, nous sommes tous passés par la phase que tu décris. Nous avons tous cru qu'il serait un jour possible de supprimer totalement les commentaires.

A un moment, on en revient, parce que plus on devient bon, mais vraiment bon, pas juste "j'ai trois ans d'expérience et je me prends pour un cador", et on découvre / on invente de nouveaux types de commentaires qui rendent notre code meilleur que le code sans commentaire (qui était lui-même meilleur que le code avec des commentaires inutiles)

Sans oublier que devoir travailler avec d'autres développeurs nous ramène à certaines réalités. L'autre développeur n'est pas plus con que moi, et pourtant il aura du mal à comprendre ce que je fais (et inversement), donc je vais lui faciliter la tache quitte à écrire des commentaires non nécessaires pour reprendre ta terminologie. Mais quelques uns, pas trop, je ne prends pas l'autre pour un débile à qui il faut tout expliquer en écrivant plus de commentaires que de code.

Et puis quand tu dis qu'il suffit de connaître le langage... pas du tout ! Dès qu'on travaille dans un domaine pointu et avec des gens qui ont des habitudes de programmation qui viennent du domaine en question, il faut connaître le domaine ainsi que les habitudes en question... et ça tu ne les trouveras ni dans le code, ni dans les commentaires, ni même dans les documentations plus ou moins associées au code. Il y a des choses qui tu ne trouveras que dans une littérature plus ou moins spécialisées, et d'autre qu'on ne peut qu'apprendre sur le tas qui seront nécessaires pour pouvoir prendre en main le code d'une grosse appli dans un domaine pointu. "Il suffit de connaître le langage" est une idée d'une grande naïveté.

Bref, une bonne partie de ce que tu écris montre que tu n'es pas encore vraiment à la hauteur du débat.

[souviron34]

nous on ne fait pas passer un code fait "sous contraintes incompatibles avec la recherche de qualité" pour un code bien écrit.

Alors là, permet-moi un énorme ............

Je m'excuse, mais comme CodeurPlusPlus l'a dit, comme je l'avais déjà signalé dans mon post précédent, quand tu associes ça avec :

Libre à vous de ne pas être d'accord, mais pas de faire passer nos points de vue pour des gamineries sans fondements solides.

Le code est destiné à être lu, oui, et par des gens dont l'employeur est au minimum en droit d'espérer qu'ils connaitront un tout petit peu le langage avec lequel ils travaillent.

C'est justement ce qui nous fait affubler vos commentaires d'inexpérience... On ne parle pas de gamineries, on dit que c'est sans expérience, c'est tout.. De la théorie pure.. basée sur l'inexpérience, sans plus... Pas grave, c'est normal, mais simplement ne pas juger la qualité d"un code ou d'un programmeur à l'aune de votre (in)expérience...



Je te cite un exemple: le dernier gros projet sur lequel j'ai travaillé, c'est le soft qui gère les trains de la SNCF... : celui qui empêche qu'il y ait des collisions, qui permet de savoir quel train arrive à quelle heure à quelle gare, avec telle locomotrice, tant de wagons, telle mesure d"économie d"energie, etc....

Le code a 35 ans, créé et raffiné par des cheminots passés ingéniéurs, et comprend tous les types de trains de la SNCF, des michelines de campagne ou de montagne au TGV, à l'Eurostar, et même les trains du Portugal, puisque le logiciel y est installé aussi..

Le code est en Fortran (77). Je connais très bien le Fortran (77). Le code va être ré-écrit (en partie). On me demande d'analyser le coeur, et d'en sortir l'architecture, et les données, et le détail des traitements... savoir si on touche ou pas au coeur (c'est pas mal critique, hein ? une erreur, et tout le réseau SNCF s'arrête, et des collisions ou déraillements avec mort d'hommes se passent, jusqu'à un possible accident sous la Manche avec toutes ses conséquences)...

Le code est très bien écrit.. Je connais très bien le langage.

Mais HEUREUSEMENT que ces cheminots ont mis des beaux commentairee explicatifs.... Ils sont tous partis à la retraite ou morts, je n'ai personne à qui demander pourquoi on fait dans cet ordre plutôt que dans celui-là cet algo-ci, pourquoi le poids d'un wagon est associé à sa position dans le train, pourquoi et comment le nombre d'essieux intervient, quelle est l'influence de la pente sur la consommation électrique, etc etc..... Je suis SEUL devant le code, avec quelques documentaitions qui restent, au bout de 35 ans... et du code, avec des équations, des if TGV else... .... HEUREUSEMENT qu'ils avaient faits de la doc... Sauf que la doc externe, comme c'était des cheminots, elle utilise des mots et des concepts de cheminot, par-ci par-là. (et encore, on a de la chance parce que c'est la SNCF, et qu'elle garde tout.. Dans une boite normale il n'y a plus de docs externes du tout, après 10 ou 15 ans).. Alors je saisis le sens global, mais le détail de l'algo, il faut que je rentre dedans... Et que fait cette valeur, pourquoi elle est affectée là et pas ailleurs, etc, HEUREUSEMENT qu'ils ont mis des commentaires dans le code...

Même avec tout ça, il me faut 3 mois pour avoir l'organigramme et la structure des données et des appels, et la description des algos...



Ensuite, quand je lis :

Nous on se fait une idée de ce qu'est un code bien écrit

C'est justement là le problème... Il ne faut pas UNE IDEE.... Il faut de la réalité, pour les suivants....

TON idée n'est pas forcément la même que celle de koala, qui ne sera pas celle de el_slapper, qui ne sera pas celle de CodeurPlusPlus, qui ne sera pas la mienne, qui ne sera pas....

De plus, dans 10 ans on aura appris aux étudiants un autre paradigme, une manière différente, on voudra traduire ton soft dans un autre langage, et là, bababoummmmmmm... Le mec qui vient pensera encore plus différemment, et même si il connait le langage, comme moi avec le truc de la SNCF, eh ben t'es sacrément content - et ton employeur aussi - que tu aies des commentaires.. Ne pas les avoir peut signifier simplement foutre le soft à la poubelle et recommencer de zéro... Sauf que quand ça se chiffre en millions, on hésite... Mais pas trop si on comprend rien...




Tu veux savoir ce que ça donne un bon et même excellent code sans commentaires ?? L'assemnleur, c'est pas trop compliqué,et même moi sans formation informatique je me débrouille... Je suppose que pour toi c'est un jeu d'enfant.. Dé-assemble une biblothèque que tu ne connais pas et essaye de comprendre et retrouver le code original : les fonctions, les varaibles, et l'arborescence....... Mais pour que ce soit le fun, essaye avec une bibliohtèque de 8 à 10 000 lignes pour commencer... Ensuite, SI et QUAND tu y arrives, imagine alors que c'est pas 10 000 lignes, mais 10 millions de lignes.... :

[Matthieu Vergne]

Bon j'arrête là vu qu'à force on s'énerve, on simplifie parce qu'on en a marre, et les gens sautent sur le moindre petit mot qui les arrangent pour te contredire comme si t'étais un extrémiste fanatique.

Je terminerai donc là dessus:
- Je codais à l'école, je code au boulot, je code chez moi, et cela depuis 9 ans. Certes pas 30, mais pas 3 non plus, et pas juste de temps en temps.
- J'ai participé à 2 projets d'ERP différents (entre autres), donc la vie réelle, les domaines imbriqués et le travail d'équipe ne me sont pas inconnus et font partis de ce qui m'a amené à mes convictions actuelles.
- Moi aussi je met des commentaires dans mon code : quand je fais de l'optimisation, qui va au delà des connaissances du domaine représenté à proprement parler, je met des commentaires pour dire pourquoi j'utilise telle ou telle optimisation. Déjà dit, plusieurs fois d'ailleurs. Je met aussi des TODO et des FIXME, mais ça n'apporte rien à la compréhension du code existant vu que ça concerne du code à faire plus tard, et qui ont vocation à disparaitre avant la livraison, remplacés par le code correspondant.
- J'aime la pédagogie et en ait déjà fait (et en fait de temps en temps quand j'en ai l'occasion), aussi je suis particulièrement sensible à "ce qui est facilement compréhensible" et "ce qui porte à confusion".

À partir de là, relisez et interprétez comme vous le voulez. Rendez-vous au prochain thread sur le même sujet {^_^}.

[souviron34]

Ne te vexe pas, on dit juste que la qualité du code est relative, pas absolue...

Et que pour qu'elle tende vers un certain absolu, il faut des commentaires, qui permettent simplement de transmettre ce qui est contenu, que ce soit l'algo, le cas particulier, l'utilisation d"une structure ou d'une optimisation, comme si tu l'expliquais à un gars qui dois reprendre ton boulot demain matin...

C'est tout ce qu'on dit...




C'est juste que vous avez l'air de prétendre qu'un code peut être jugé "de bonne qualité" ou "de mauvaise qualité"...juste au vu du code... Et nous on dit non, les commentaires font partie de la qualité...

[Matthieu Vergne]

Mais tout est relatif. Si cet argument suffisait, la question n'aurait tout simplement pas de réponse (tout du moins satisfaisante). Et il n'y en aurait pas beaucoup qui en aurait d'ailleurs. Ça ne l'est plus à partir du moment où tu formalises en posant des définitions clairement bornées (au sens mathématique). Mais même si on fait cet effort, encore faut-il que les autres acceptent ces définitions, mais c'est là que le bas blesse.

C'est pas vraiment le fait d'être vexé mais plutôt le fait que je passe beaucoup de temps à rédiger mes posts, que j'en ai rédigé un petit paquet et que ça tourne en rond. Donc pas besoin d'aller plus loin, qu'est-ce que tu veux que je te dise {'^_^} ? Les idées ont été semées, certains ça a pris d'autres ça a été arraché comme de la mauvaise herbe. Je vais pas en rajouter si ce n'est plus productif, ça sert à rien. On va laisser l'eau passer sous les ponts et on en remettra une couche quand d'autres se poseront à nouveau naïvement la question. Si d'ici là mon avis a changé, tant mieux pour certains et tant pis pour d'autres, sinon ce sera l'inverse.

[koala01]

C'est justement ce qui nous fait affubler vos commentaires d'inexpérience... On ne parle pas de gamineries, on dit que c'est sans expérience, c'est tout.. De la théorie pure.. basée sur l'inexpérience, sans plus... Pas grave, c'est normal, mais simplement ne pas juger la qualité d"un code ou d'un programmeur à l'aune de votre (in)expérience...

Là, tu n'as vraiment pris que ce qui t'arrange.

Juste après, j'ai précisé

Bien sur, on peut parler de langage comme perl, qui est un langage très efficace (de ce que j'en ai entendu) mais qui rend les choses, même les plus simples, particulièrement difficiles à lire (ou les langages fonctionnels auxquels j'ai énormément de mal à me faire).

Je vais donc être plus clair : je ne connais pas perl et je n'ai jamais accroché avec le moindre langage fonctionnel... Ce n'est pas compatible avec mon "système de pensée" dirons nous.

Face à un de ces langages, tu pourras mettre des commentaires jusqu'à plus soif, il me permettront de comprendre ce que le programme, la fonction est sensé(e) faire, mais cela s'arrêtera bien là.

Or, si on me place comme développeur face à ce programme, ce n'est pas seulement pour pouvoir dire "tiens, cette fonction est sensée faire ceci ou cela", quelqu'un qui sait lire la langue dans laquelle les commentaires sont écrits est capable de le faire!

Ce que l'on me demandera en tant que développeur, c'est d'apporter une solution au fait que la fonction ne fait, justement pas, ce qu'elle est sensée faire, on est bien d'accord

Si tu ne connais pas le langage dans lequel tu travailles, ou si tu n'as pas un minimum l'habitude d'un langage équivalent, tous les commentaires que tu pourras trouver ne te seront d'aucune utilité.

la question du débat est "un code bien écrit a-t-il besoin de commentaires", la réponse que Matthieu et moi-même donnons est "un code bien écrit devrait se suffire à lui même".

Est-ce que ca veut dire que l'on est opposé à toute forme de commentaire

Absolument pas: cela veut juste dire que l'on considère que la présence de commentaires est l'un des indices(car il y en a d'autres) qui auraient tendance à faire baisser la qualité d'écriture du code.

On ne dit absolument pas que c'est le cas de tous les commentaires, on dit que c'est très certainement le cas des commentaires qui ne font que paraphraser le code ou qui indiquent une étape intermédiaire au sein de la fonction (sur base de langage qui permettent l'utilisation de fonction / sous routines, évidemment).

Parce que, si tu veux un code bien écrit, tu peux "assez facilement" modifier ton code pour exprimer plus précisément ce que le commentaire qui le paraphrase veut exprimer et que tu auras sans doute tout intérêt à "extraire" les différentes étapes que tu as indiquées dans des fonctions, clairement nommées, équivalentes, à condition de vouloir le faire (et, accessoirement d'avoir le temps de le faire)

Est-ce que cela veut dire que l'on a la prétention de toujours fournir du code bien écrit Certainement pas. Cela veut dire que l'on tend vers cet objectif, que l'on va essayer de se donner les "moyens de nos ambitions" (si tant est que nous ayons les moyens de nous donner les moyens de nos ambitions ) pour y parvenir.

Est-ce que cela veut dire que l'on y arrive systématiquement Absolument pas, on a tous été confrontés à des situations dans lesquelles il fallait quelque chose "pour hier" (dans le meilleur des cas), et où l'on n'a (très certainement) pas pris le temps nécessaire à la réflexion qui nous aurait permi d'atteindre notre objectif.

Mais on ne prétendra très certainement pas que le code que l'on a du produire dans ces circonstances est "bien écrit".

Selon nos critères, un code qui contient certaines formes de commentaires (je ne reviendrai pas sur ces formes, je les ai déjà largement expliquées), est -- ad minima -- perfectible. Et c'est tout ce que l'on dit.

On ne dit pas qu'il faut le rendre meilleur, surtout s'il fonctionne correctement, on ne dit pas qu'il sera forcément facile de le rendre meilleur, et l'on ne tape très certainement pas sur celui (ou sur ceux qui se sont succédés) qui ont fourni le code tel qu'il est: on regrette que le code tel qu'il est écrit n'ait pas été "mieux" écrit, et cela s'arrête là.

Et je vais même aller jusqu'à dire que, plus un code est vieux, plus il a été remanié au fil du temps, plus on peut parfaitement comprendre qu'un code puisse nous paraitre "mal écrit" selon nos critères.

Est-ce que cela signifie d'office que l'on va essayer de le remanier à tout prix Certainement pas : S'il fonctionne correctement, on n'y touchera absolument pas, s'il ne fonctionne pas correctement, on limitera notre intervention à ce qui est nécessaire pour qu'il fonctionne, quitte --s'il est possible de le faire -- à modifier la partie à laquelle on touche de manière à ce qu'elle se rapproche de nos critères qui font que l'on considère qu'un code est "bien écrit".


Mais le problème ne se situe pas au niveau du code vieux de cinq, dix ou quinze ans, qui a été remanié un nombre incalculable de fois, le problème se situe au niveau du "nouveau" code, celui qui est écrit maintenant: ce n'est pas parce que le "vieux" code respectait (ou non) des règles propres aux "standards de l'époque" qu'il faut obligatoirement continuer à respecter ces règles qui ont très certainement démontré leurs limites au fil du temps si elles ont été adaptées pour être ce qu'elles sont aujourd'hui.

Après, il y a tout le problème du code écrit il y a trente ans qui, dés le départ, ne respectait pas les règles de l'époque (à l'époque, la règle était "maximum 50 lignes par fonctions, par exemple).

Mais ce code là, même à l'origine, n'aurait très certainement pas été considéré comme "bien écrit" même par quelqu'un qui l'aurait relu, en suivant les règles en cours à l'époque.