Discussion :

[souviron34]

Dans le contexte où je travaille (c'est potentiellement différent ailleurs selon les méthodes et outils utilisés), c'est typiquement le style de commentaire qui, sauf cas extrêmement particulier, ne sert à rien [1]. Pour moi, la problématique de suivi des modifications/corrections de bug est faite via l'outil de gestion de conf (CVS, SVN ou autre) et non via les commentaires dans le code.

Désolé, mais je ne peux être d'acord avec ça, pour plusieurs raisons..

D'une part, qui garanti que dans 10 ou 15 ans ce sera toujours sous cvs ?

D'autre part, la référence au numéro de bug fait peut-être référence à une doc Excel ou autres, figurant dans un répéertoire Service Clients , archivé depuis 5 ans.. Si tu n'as pas le numéro, aucune idée de à quoi correspond cette ligne, aucune idée du détail de ce qui avait été remarqu, ni des discussions avec les utilisateurs, ni des décisions prises...

En outre référencé un numéro de ligne de code dans un commentaire alors que la ligne est susceptible de se déplacer au fil des ajouts/corrections n'est clairement pas une bonne idée.

Là par contre 100% d'accord...

Un autre style de commentaire assez fréquent qui n'a aucune raison d'être [2], c'est le commentaire sur les fermetures de blocs référençant l'ouverture de bloc. Par exemple

Code :

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

1
2
3
4
if(Var == 8)
{
   ....
} // if(Var == 8)

100% d'accord également..

Sauf si la boucle ou le if est grand (> 50 lignes à vue de nez)

Je pense que ça peut se résumer à deux questions:

• Le cartouche (que j'ai aussi appelé commentaire d'en-tête) est-il un simple commentaire de code ? Pour moi oui.
• La description des APIs doit-elle être faite dans le code via le cartouche de commentaire ou entièrement déportée dans une documentation totalement distincte du code ? Pour moi, ça doit être fait dans le code via le commentaire. Ma position vient du fait que j'y trouve plusieurs avantages par rapport à ma façon de travailler.

je suis d'accord avec toi, mais il y a le 3ième point, que tu ne mentionnes pas, et qui est du commentaire intra-code..





Enfin, j'ai retrouvé les références sur Agile et la documentation...

Elles figurent en plusieurs endroits, mais en particulier sur le thread déjà cité (Projets Informatiques : les bonnes pratiques).

On peut lire ici (post #197) un extrait :

Pour agile, les fondamentaux sont :
Individuals and interactions over processes and tools
(Personnes et interaction entre les personnes avant les process et les outils)
Agile remet clairement le développeur et l'équipe au coeur du principe, partant du principe que dans sa construction et dans sa gestion, les process et les outils seront utilisés comme support d'amélioration plutôt que comme base de travail.

Working software over comprehensive documentation
(Produit efficient prioritaire à une documentation)
La culture du résultat est plus important que la documentation

Customer collaboration over contract negotiation
(Collaboration client plutôt que négociation commerciale)
Culture du fair deal, le résultat n'est pas le fruit d'un engagement contractuel mais d'une relation avec le client.

Responding to change over following a plan
(Adaptation aux changements plutôt que Suivi de plan projet)
Croire davantage à la capacité d'adaptation de l'organisation qu'à la capacité de l'organisation à gérer un projet.

Il n'est dit nulle part "pas de commentaires"... Juste pas une "documentation exhaustive".. ce qui et le propre des autres méthodes dites "traditionnelles", et ce qui se fait avec les "méthodologies" agile, ême si elles prônent le contraire.

De même, le Manifeste Agile (http://fr.wikipedia.org/wiki/Manifeste_Agile), à la base des méthodologies du même nom, prône :

Les 4 valeurs
Les quatre valeurs fondamentales Agiles sont[2] :

• L’interaction avec les personnes plutôt que les processus et les outils.
• Un produit opérationnel plutôt qu’une documentation pléthorique.
• La collaboration avec le client plutôt que la négociation de contrat.
• La réactivité face au changement plutôt que le suivi d'un plan.

Les 12 principes

• Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
• Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
• Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
• Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.
• Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
• La méthode la plus efficace de transmettre l'information est une conversation en face à face.
• Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
• Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
• Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.
• La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.
• Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.
• À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Où voyez-vous "pas de commentaires" ??

Et quand j'explore les différentes méthodes, nulle part je ne vois de telle recommandation..

Ce que je vois est ce qui est mentionné dans les valeurs fondamentales :

[*]Un produit opérationnel plutôt qu’une documentation pléthorique.

Mais si vous pensez que cela signifie pas de commentaires, ou de docs, ou généré automatiquement, c'est que vous n'avez jamais approché un développement "traditionnel", où en général on considère qu'on ne fait pas une seule ligne de code avant d'avoir tout mis sur le papier, soit environ 5000 pages minimum...

Et que les "méthodes" agiles, telles que je les vois appliquées ici-même et dans l'industrie, font à peu près la même chose, bien qu'en ayant réduit, mais en ayant inventé un nouveau langage (UML).

Je prône (déjà dit dans l'autre thread) une approche agile...

Mais il n'est nulle part fait mention de ne pas mettre de commentaires.. Juste de ne pas "générer du papier", c'est à dire "pléthorique", c'est à dire 10 fois plus de papier que le total du logiciel (pas qu'une fonction, hegros)....

[Matthieu Brucher]

Désolé, mais je ne peux être d'acord avec ça, pour plusieurs raisons..

D'une part, qui garanti que dans 10 ou 15 ans ce sera toujours sous cvs ?

On part du principe qu'il y a un suivi du SI dans l'histoire. Si tu considères qu'il n'y en a pas, je pense qu'on va en rester là.

D'autre part, la référence au numéro de bug fait peut-être référence à une doc Excel ou autres, figurant dans un répéertoire Service Clients , archivé depuis 5 ans.. Si tu n'as pas le numéro, aucune idée de à quoi correspond cette ligne, aucune idée du détail de ce qui avait été remarqu, ni des discussions avec les utilisateurs, ni des décisions prises...

Encore une fois, tu pars du principe qu'on ne suit aucune bonne pratique.
La question d'origine était comment écrire du code propre. Cela va aussi avec des bonnes pratiques SI. Si tu considères qu'on ne les a pas, à quoi ça sert de discuter de ce qu'est un code propre ?

Sauf si la boucle ou le if est grand (> 50 lignes à vue de nez)

Mais comme un code propre n'a pas de fonction de plus 50 lignes, je ne vois pas ce que ton commentaire fait là.

Enfin, j'ai retrouvé les références sur Agile et la documentation...
[...]
Mais il n'est nulle part fait mention de ne pas mettre de commentaires.. Juste de ne pas "générer du papier", c'est à dire "pléthorique", c'est à dire 10 fois plus de papier que le total du logiciel (pas qu'une fonction, hegros)....

Toutes les méthodologies agiles partent du principe qu'on a un code propre. Or par définition, il s'agit de faire tout le contraire (ou presque) de ce que tu fais (cf la littérature abondante existante sur le code propre dans un développement agile). Bref, on n'avance pas.

[gl]

Je n'ai rien fourni comme exemple. Si tu en veux, je te conseille de lire Clean Code.

Sur tes conseils, j'ai jeté un œil dessus.
Et concernant le nom des fonctions, je reste sur mes positions. Dans les exemples que j'ai lu, il y a effectivement des cas où le nom est amplement suffisant, mais pour d'autres - plus complexe ou plus complète - j'ai bien du lire le code de la fonction pour comprendre ce qu'elle faisait exactement (et pourtant, il faut le reconnaitre, les choix de nom sont plutôt très bien dans ce livre.

En outre, de ce que j'ai lu (certes en diagonale) dans le chapitre commentaire, sa position est somme toute assez proche de la mienne :

• Il ne rejette pas impérativement tout les commentaires (pour reprendre les terme "sometimes it is usefull", "Sometimes reasonable") même s'il n'encourage pas leur usage de manière immodérée.
• Il semble plutôt favorable aux commentaires Javadoc des APIs (je cite : "If you are writing a public API, then you should certainly write good javadocs for it."), qui est la position que je défends ici (la présence du cartouche de commentaire en en-tête de fonction) tout en mettant en garde contre les dérives possibles de ces commentaires.

Petit aparté : je vais lire attentivement ce livre qui semble intéressant d'autant plus que l'auteur explique ces choix et conçoit qu'il puisse y avoir des exceptions dans les cas exceptionnels (ce dernier point m'a toujours semblé important et pourtant bien souvent absent des publication "qualité de code" et des normes de programmation).

[hegros]

gl, pour la première raison que tu évoques c'est personnel du coup l'objectivité et la pertinence mise de côté c'est une pratique trés répandue déjà puis cela se discute plus difficilement.

L'exemple que tu as donné correspond grosso-modo à ce que j'aurais écrit (bien que j'aurais plutôt mis substring que string).

Toutefois ça ne réponds pas à la question que j'avais posée. La question faisait suite à la remarque de Matthieu

La technique de nommage ne s'applique pas qu'au nom d'une fonction mais aussi à tout son comportement. Il n'est donc pas possible de respecter ta contrainte car en pratique la technique de nommage s'applique aussi sur le corps de la fonction soit en C++ header + implémentation.

[*]Le cartouche (que j'ai aussi appelé commentaire d'en-tête) est-il un simple commentaire de code ? Pour moi oui.

La grande différence c'est qu'une cartouche est plutot écrite en langage formel contrairement à une description d'api ce qui par rapport au % commentaire % code pose problème puisque si je n'utilise pas de cartouche (tout ce qui n'est pas formalisé) n'est pas exploitable informatiquement, la valeur n'est donc pas la même.


Souviron quand méthode agile dit pas de documentation exhautive cela concerne TOUT les documents à commencer biensûr par le code et les commentaires...

[gl]

Désolé, mais je ne peux être d'acord avec ça, pour plusieurs raisons..

D'une part, qui garanti que dans 10 ou 15 ans ce sera toujours sous cvs ?

D'autre part, la référence au numéro de bug fait peut-être référence à une doc Excel ou autres, figurant dans un répéertoire Service Clients , archivé depuis 5 ans.. Si tu n'as pas le numéro, aucune idée de à quoi correspond cette ligne, aucune idée du détail de ce qui avait été remarqu, ni des discussions avec les utilisateurs, ni des décisions prises...

Déjà je le répète, je parlais dans un contexte qui est le mieux, ce n'est pas nécessairement transposable à d'autre.

Selon le sens exacte de ta remarque sur la pérennité de l'outil de gestion de conf, j'aurais deux réponses:

• La crainte qu'on outil ne soit plus maintenu ou plus distribué : on utilise des produits dont on est relativement sur de la pérennité à plus ou moins long terme et permettant d'exporter les informations vers un autre format répandu ou dont le format peut être importé par un autre outil. Et ayant si possible un format, si ce n'est des sources ouvertes. En outre un outil ne disparaît pas du jour au lendemain. Et il est possible de l'utiliser encore même si l'éditeur vient de faire faillite au moins le temps de mettre en place une migration des données vers un nouvel outil.
• La crainte qu'en interne on décide de changer d'outil pour une raison quelconque : on est là dans un choix de notre part. J'ose espérer que lors de tel choix les conséquences aient été envisager et qu'un plan de migration des données soient prévus. Sachant que si les sauvegardes sont faites correctement, il sera toujours possible de restaurer l'ancien système en cas de problème à la migration.

Quant à conservé la référence de l'anomalie pour la tracabilité (que ce soit depuis une fichier Excel, un bugtracker quelconque, une mail ou autre), oui c'est indispensable. Ca fait partie des informations que je met dans les commentaires de commit dans la gestion de conf.

Sauf si la boucle ou le if est grand (> 50 lignes à vue de nez)

D'une part, il m'arrive très très rarement d'avoir des boucles ou des if aussi long, surtout s'ils sont imbriqués.
D'autre part, je préfère utiliser les possibilités offertes par les éditeurs que j'utilise pour gérer ce genre de chose.
En outre une indentation correcte permet déjà de facilement repérer les blocs.

je suis d'accord avec toi, mais il y a le 3ième point, que tu ne mentionnes pas, et qui est du commentaire intra-code.

Le code intra-code (ie dans le corps de la fonction) n'est pas abordé dans le message que tu cites, car ne correspond pas à la discussion à ce moment là.

J'en ai parler par ailleurs. Ma position est que c'est d'un usage plutôt rare essentiellement pour clarifier un choix à priori douteux et prévenir une modification intempestive ou pour documenter une ruse dans le code dont on ne peut pas se passer.
Les autres commentaires intra-code sont :

• Soit des paraphrase du code qui peuvent être enlevés.
• Soit des commentaires de travail (TODO, description des grandes lignes de la fonction avant implémentation) qui seront à terme enlevé.

Pour le point que tu avais abordé concernant la description de l'algorithme, celle-ci n'a pas sa place dans le corps de la fonction.
Idéalement elle se trouve dans un document externe (public ou interne) avec éventuellement une référence vers ce document dans le cartouche de la fonction.
Dans les cas extrêmes, on peut imaginer de l'avoir dans le cartouche de la fonction.

[gl]

Mais comme un code propre n'a pas de fonction de plus 50 lignes, je ne vois pas ce que ton commentaire fait là.

C'est une règle qui m'a toujours fait bondir que de fixer une taille maximale à une fonction.

J'aurais plutôt tendance à préconiser des principes généraux:

• Une fonction fait une seule chose.
• Tendre vers des fonctions élémentaires.
• Essayer de faire des fonctions les plus courtes possibles.
• Factoriser au maximum le code

Au final on rentre quasi systématiquement dans les contraintes de taille qu'on trouve à droite ou à gauche. Mais ce n'est pas la crise le jour ou exceptionnellement une fonction est un peu plus longue.

Surtout qu'à mon avis il est pire d'avoir deux fonctions qui ne correspondent à rien et un découpage arbitraire que d'avoir une fonction de 51 lignes.

Donc oui, une fonction fait moins de 50 lignes, sauf cas exceptionnel.

Pour la petit histoire, la dernière fois que le sujet avait été abordé, en regardant le projet sur lequel je travaillais à l'époque en C, j'avais une fonction sur une centaine qui faisait dans les 80-100 lignes de code utile, il s'agissait du moteur d'une machine à état toutes les autres faisait moins de 50 LOC donc une bonne partie (environ 70-80%) en dessous de 20 LOC. Le tout sans suivre aveuglément une règle qui fixe d'autorité une limite, comme quoi ça vient tout seul .

[gl]

La technique de nommage ne s'applique pas qu'au nom d'une fonction mais aussi à tout son comportement. Il n'est donc pas possible de respecter ta contrainte car en pratique la technique de nommage s'applique aussi sur le corps de la fonction soit en C++ header + implémentation.

Donc on est bien d'accord que les commentaires peuvent être utiles pour publier une API, l'utilisateur n'ayant normalement pas l'accès au code source.

A destination des développeurs et mainteneurs d'un projet, les commentaires sont moins utiles, même s'ils évite de devoir rentrer dans le corps d'une fonction et de redescendre tout la hiérarchie de fonction lorsque l'on cherche juste une information simple. Ce n'est pas indispensable mais ça peut être parfois un petit gain de temps.

La grande différence c'est qu'une cartouche est plutot écrite en langage formel contrairement à une description d'api ce qui par rapport au % commentaire % code pose problème puisque si je n'utilise pas de cartouche (tout ce qui n'est pas formalisé) n'est pas exploitable informatiquement, la valeur n'est donc pas la même.

Le contenu du cartouche doit suivre un format précis pour être pleinement utile pas être en langage formel.
Généralement j'utilise un cartouche au format doxygen avec les descriptions en anglais

Souviron quand méthode agile dit pas de documentation exhautive cela concerne TOUT les documents à commencer biensûr par le code et les commentaires...

Je me permet de commenter à la place de Souviron. Pas de documentation exhaustive ne veut pas dire pas de documentation du tout. Ma compréhension (peut être ai-je tort) de ce principe est de supprimer le superflu et de ne conserver que l'essentiel (qui est malheureusement une notion plutôt subjective.

[hegros]

Je me permet de commenter à la place de Souviron. Pas de documentation exhaustive ne veut pas dire pas de documentation du tout. Ma compréhension (peut être ai-je tort) de ce principe est de supprimer le superflu et de ne conserver que l'essentiel (qui est malheureusement une notion plutôt subjective.

Le code est un document, il est le document de référence de la programmation et en général il est très conséquent hors commentaire. Cela n'avait pas l'air de te gener que le % de commentaire > % de code pourtant sans commentaire cela devrait fonctionner aussi c'est donc superflu pour la production par contre pour le knownledge effectivement c'est très pratique et utilisé, la publication d'une api en est un exemple qui l'illustre bien.


En même temps pour alléger un tel document il n'y a pas beaucoup de marge. Soit en compactant le code (par exemple avec un nommage explicite des fonctions, variables etc..) soit en supprimant une part des commentaires non essentiel et nous nous retrouvons au problème que tu exposes concernant la pertinence du commentaire

J'espère que Souviron arrive à suivre

[gl]

Cela n'avait pas l'air de te gener que le % de commentaire > % de code pourtant sans commentaire cela devrait fonctionner aussi c'est donc superflu pour la production par contre pour le knownledge effectivement c'est très pratique et utilisé, la publication d'une api en est un exemple qui l'illustre bien.

Vision un peu extrême quand même. En allant par là, il n'est pas nécessaire de conserver le code une fois le binaire généré puisque le binaire généré fonctionne très bien sans le code

[Garulfo]

Le code est un document, il est le document de référence de la programmation et en général il est très conséquent hors commentaire. Cela n'avait pas l'air de te gener que le % de commentaire > % de code pourtant sans commentaire cela devrait fonctionner aussi c'est donc superflu pour la production par contre pour le knownledge effectivement c'est très pratique et utilisé, la publication d'une api en est un exemple qui l'illustre bien.[...]

Ouahhh J'ai rien compris... Pourrais-tu avec une touche de syntaxe améliorée, comme la ponctuation, s'il te plait ?

Pour juste le début : le code est un livrable, mais n'est pas un document dans le sens utilisé en GL. Il n'est pas une référence de programmation par exemple. Il est le produit du projet. La référence du code c'est le document de conception.

Mais n'étant pas certain de ce que tu as dis, je n'ose pas trop affirmer que ce n'est pas ce que tu as voulu dire en fait

[hegros]

Vision un peu extrême quand même. En allant par là, il n'est pas nécessaire de conserver le code une fois le binaire généré puisque le binaire généré fonctionne très bien sans le code

Si parce que quand les machines plantent il faut reconstruire le binaire

Note : la sauvegarde d'un logiciel sans le matériel qui va avec pour l'exploitation et la compilation est quasi-inutile.

[hegros]

Ouahhh J'ai rien compris... Pourrais-tu avec une touche de syntaxe améliorée, comme la ponctuation, s'il te plait ?

C'est pourtant clair on chasse les odeurs dans le fichier source. Ce qui n'est pas exploitable n'a rien à y faire à mon sens car si une machine ne peut l'exploiter un développeur venant 20 ans après le pourra mieux ?

Soit mise à part avec une écriture formalisée (pre/post condtion par exemple) ou pour le knownledge je ne les trouve pas pertinents la plupart du temps quand je les rencontre dans le code source.(expérience personnelle)

Pour juste le début : le code est un livrable, mais n'est pas un document dans le sens utilisé en GL. Il n'est pas une référence de programmation par exemple. Il est le produit du projet. La référence du code c'est le document de conception.

Oui le code est un livrable et conceptuellement cela te pose un probléme de le voir comme un document ? c'est finalement un .cpp ou .java

Ce n'est pas la référence de code à quoi j'imaginais mais le produit de l'activité d'implémentation/programmation et non de la conception.

En même temps ma plus grande expérience c'est dans le domaine de la production industriel...

[souviron34]

On part du principe qu'il y a un suivi du SI dans l'histoire. Si tu considères qu'il n'y en a pas, je pense qu'on va en rester là.


Encore une fois, tu pars du principe qu'on ne suit aucune bonne pratique.
La question d'origine était comment écrire du code propre. Cela va aussi avec des bonnes pratiques SI. Si tu considères qu'on ne les a pas, à quoi ça sert de discuter de ce qu'est un code propre ?

JUSTEMENT PARCE QUE CELA TIENT DU CODE PROPRE....

C'est orthogonal aux bonnes pratiques....

Tu changes de boîte avec TON soft, ta boîte change, le projet est arrêté après la première production, puis repris 10 ans après sur d'autres machines, vous étez avec cvs mais là votre directeur technique vous fait passer sous Rational, etc etc...

Là, dans ce thread, on parle de propreté d'un CODE, pas d'un environnement de développement/maintenance/ à prioris/ bonnes pratiques de gestion de projet...

Mais comme un code propre n'a pas de fonction de plus 50 lignes, je ne vois pas ce que ton commentaire fait là.

Ah oui ?

qui a dit ça ?

Que ce soit la théorie, je veux bien...

Mais la pratique est autre chose.......

Et ce n'est pas, et ne doit pas être une règle absolue et brutale....

Toutes les méthodologies agiles partent du principe qu'on a un code propre. Or par définition, il s'agit de faire tout le contraire (ou presque) de ce que tu fais (cf la littérature abondante existante sur le code propre dans un développement agile). Bref, on n'avance pas.

C'est on ne peut plus faux....

Relis la citation du Manifeste Agile...

Les méthodologies agiles partent du principe qu'on va faire un logiciel qui fait ce qu'il doit faire...

Sans plus...

Il n'est rien dit sur la notion de "code propre"...

J'ajouterais que, comme on l'avait souligné dans l'autre débat, comme toute méthodologie, les méthodologies agiles sont des méthodologies de gestion de projet..

Le sujet de ce thread est indépendant de savoir avec quelle méthodologie le projet est géré... Que ce soit en Waterfall ou en XP, c'est du pareil au même quant à la "propreté" du code..

Encore une fois, la "propreté" d'un code s'évalue hors du contexte de développement et de maintenance traditonnel, de l'équipe. C'est intrinsèque..

Je reprend ici l'exemple donné plus bas : admettons que vous deviez envoyer votre code à une Agence Externe d'agrément, pour Audit.. Ils se fichent pas mal de vos outils locaux, de votre manière de gérer les versions, de votre méthodologie de développement. Ils vont juste passer votre code au crible...

Et par exemple dans le genre de cas dont je m'occupe (et d'après ce qu'ils disent Garulfo et B.A.F. aussi) depuis un certain nombre d'années, c'est un audit où l'équipe a disparu... ou en tous cas où on n'a pas accès aux documents internes.. C'est donc indépendant totalement de l'environnement de l'équipe ou du développement...

Souviron quand méthode agile dit pas de documentation exhautive cela concerne TOUT les documents à commencer biensûr par le code et les commentaires...

Euh.. Je crois que tu ne sais pas de quoi ils parlent en parlant de ça...

Garulfo, B.A.F., elitost, moi, et un certains nombres d'autres ici savent très bien ce que sont les "documentations pléthoriques" auxquelles ils se réfèrent, et ça n'a aucun , mais alors aucun rapport, avec le code..

Ce sont les Dictionnaires, Specs Systèmes, Fonctionnelles, Conceptions Préliminaires, Détaillées, documents de test unitaires, fonctionnels, systèmes, sous-tendus par le cycle en V traditionnel..

TOUS DES DOCUMENTS EXTERNES AU CODE ...............


(se référer aux cycles traditionnels et à la partie "documents" de ces cycles)

Selon le sens exacte de ta remarque sur la pérennité de l'outil de gestion de conf, j'aurais deux réponses:

• La crainte qu'on outil ne soit plus maintenu ou plus distribué : on utilise des produits dont on est relativement sur de la pérennité à plus ou moins long terme et permettant d'exporter les informations vers un autre format répandu ou dont le format peut être importé par un autre outil. Et ayant si possible un format, si ce n'est des sources ouvertes. En outre un outil ne disparaît pas du jour au lendemain. Et il est possible de l'utiliser encore même si l'éditeur vient de faire faillite au moins le temps de mettre en place une migration des données vers un nouvel outil.
• La crainte qu'en interne on décide de changer d'outil pour une raison quelconque : on est là dans un choix de notre part. J'ose espérer que lors de tel choix les conséquences aient été envisager et qu'un plan de migration des données soient prévus. Sachant que si les sauvegardes sont faites correctement, il sera toujours possible de restaurer l'ancien système en cas de problème à la migration.

Voir plus haut ma remarque à Matthieu ...


Il est illusoire de se baser sur des outils externes pour la pérennité et le traçage d'un logiciel....

C'est une bonne stratégie à court terme, mais c'est totalement illusoire sur un moyen ou long terme (supérieur à 5 ou 7 ans).

(et que le choix soit de ta part, tu te mets le doigt dans l'oeil.. C'est une organisation qui décide, et tu n'as pas (souvent) ton mot à dire.. Et si tu changes d'organisation, c'est pire.. Et quand le matériel de sauvegarde change, c'est aussi pire...)

Pour le point que tu avais abordé concernant la description de l'algorithme, celle-ci n'a pas sa place dans le corps de la fonction.
Idéalement elle se trouve dans un document externe (public ou interne) avec éventuellement une référence vers ce document dans le cartouche de la fonction.
Dans les cas extrêmes, on peut imaginer de l'avoir dans le cartouche de la fonction.

Je ne sais pas où j'avais soulevé ce point..

Mais c'est également ce que je recommande, mais pas dans les cas extrêmes. Dans TOUS les cas , une fonction qui utilise un algo complexe, l'algo doit être décrit dans le cartouche. Et quand il est moins complexe, et qu'on le trouve dans la littérature (un livre, pas un site internet (les adresses changent, les répertoires deviennent indisponibles..), alors la référence (page y compris) doit figurer...

C'est une règle qui m'a toujours fait bondir que de fixer une taille maximale à une fonction.

Je me permet de commenter à la place de Souviron. Pas de documentation exhaustive ne veut pas dire pas de documentation du tout. Ma compréhension (peut être ai-je tort) de ce principe est de supprimer le superflu et de ne conserver que l'essentiel (qui est malheureusement une notion plutôt subjective.

Mais cependant correcte

Le code est un document, il est le document de référence de la programmation et en général il est très conséquent hors commentaire.

Libre à toi de penser ceci, cependant ce n'est pas une bonne pratique, et tu t"en rendras vite compte...

Cela n'avait pas l'air de te gener que le % de commentaire > % de code

Non, ça ne me dérange pas du tout, si c'est réellement explicatif....

Et c'est même idéal... quand l'algo est complexe, ou la fonction optimisée, ou l'article de référence difficilement trouvable, ou le principe assez simple...

pourtant sans commentaire cela devrait fonctionner aussi c'est donc superflu pour la production par contre pour le knownledge effectivement c'est très pratique et utilisé, la publication d'une api en est un exemple qui l'illustre bien.

Encore une fois, tu tombes dans un travers : tu ne vois que la partie "utilisation" d'une bibliothèque.. Si un jour on te demande de l'améliorer ou de la refaire, ou de la traduire dans un autre langage, tu as intérêt à avoir plus dans le code que juste la définition de l'API..

En même temps pour alléger un tel document il n'y a pas beaucoup de marge. Soit en compactant le code (par exemple avec un nommage explicite des fonctions, variables etc..) soit en supprimant une part des commentaires non essentiel et nous nous retrouvons au problème que tu exposes concernant la pertinence du commentaire

J'espère que Souviron arrive à suivre

Je suis difficilement

Mais il est bien évident que le problème central est que les commentaires soient pertinents par rapport à leur niveau : intra-code, cartouche, et extra-code...

Et il est bien évident que c'est assez subjectif..

Mais encore une fois, une certaine objectivité consiste à se placer du point de vue d'un programmeur ne connaissant rien à l'antériorité de ce que tu as fais, et qui déboule dans le code... La pertinence sera ce qui lui permet de se débrouiller sans avoir à lire le code ligne à ligne (et se torturer la cervelle pendant 3 jours sur 50 lignes) afin d'exposer (par exemple à son supérieur en vue d'un audit) ce que fait ce bout de code...

Note : la sauvegarde d'un logiciel sans le matériel qui va avec pour l'exploitation et la compilation est quasi-inutile.

Ah bon ????

Eh bien alors nous vivons tous dans l'inutilité

Car lequel d'entre vous ne sauvegarde pas ses fonctions persos ??

Et ce qui est vrai pour vous l'est également pour les entreprises..

Heureusement que les codes ne dépendent que très peu des machines sur lesquelles ils tournent !!!

Un prog Windows, faudrait le refaire tous les ans !!!!

Par exemple un bon programme C écrit de manière portable se transporte facilement depuis 25 ans d'un MicroVax à un Sun à un HP à une Silicon à un PC Linux...

Les compilos, si tu marches avec gcc (c, c++, Fortran, Java, Ada, et autres), c'est dispo partout...

je crois que tu délires là...

Un programme se sauvegarde au contraire indépendamment de sa machine..

Que l'on sauvegarde en parallèle des options de compils, des trucs comme ça, oui...

Mais simultanément des machines et des compilos ??

[zaventem]

Factoriser au maximum le code

Oui, à condition me mesurer parfaitement les implications et de connaitre les raisons de la duplication de code.

J'ai dernièrement subit la refactorisation par un nouveau qui venait d'arriver

Un code semblable à

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle ...)
{
code 1
};
 if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle...)
{
code 2
};
if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle...)
{
code 3;
};

est devenu entre ses mains

Code :

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

1
2
3
4
5
6
7
if(verifierPermission(...))
{
code 1
code 2
code 3
}

Certes le premier code n'est pas ce que j'appellerais un code propre mais les 3 tests représentent 3 conditions fixées par une ordonnance légale qui par hasard étaient à ce moment là identique. Lorsque l'un d'elles a changer, cela a été très amusant pour revenir en arrière.

Donc factoriser oui quand c'est possible; nettoyer le code, parfait. Il faut juste garder en tête que ceux qui ont codé avant nous (qu'il y ait 15 ans ou 15 jours) ne sont pas moins bons que nous et qu'il existe peut-être des raisons qui les ont amené à faire ces choix.

Le code est un document, il est le document de référence de la programmation

Je ne peux que m'inscrire en faux.
A la lecture du code, on ne verra jamais que ce qu'il fait, jamais ce qu'il doit faire. Le code en lui-même n'aura jamais été approuvé par le fonctionnel mais seulement son fonctionnement à un moment X.


En ce qui concerne les commentaires, ma position va sans doute à contre-courant mais elle est celle-ci "Si l'idée d'un commentaire te vient à l'esprit, écris le!". Mes arguments sont les suivants:µ

• je travaille avec des professionnels, j'estime qu'ils ont donc un minimum de bons sens pour ne pas mettre de commentaires totalement inutiles.
• le rapport de temps perdu entre sauter quelques lignes qui ne nous interressent pas et celui perdu pour comprendre un code qui ne nous parait pas clair est sans commune mesure.
• il est plus facile de supprimer un commentaire après coup de de le rajouter.

[koala01]

je n'ai pas lu la dernière page, mais j'ai lu une grande partie du débat qui porte sur les "commentaire de documentation de fonction", et j'ai l'impression que le gros du problème vient surtout du langage de référence des intervenants

En effet, gl se base principalement sur le fait qu'il utilise systématiquement deux fichiers distincts d'en-tête et d'implémentation séparés (*.c / *.cpp et *.h / *.hpp) pour créer une unité de compilation pour justifier le fait que le commentaire "cartouche de fonction" ou "d'en-tête" doit se trouver juste au dessus de la déclaration de la fonction, alors que hegros semble avoir une approche plus basée sur le C# ou le java, où la déclaration et l'implémentation se font dans un seul et même fichier, qui n'est au demeurant pas ou plus disponible pour l'utilisateur de la classe créée.

Le pire est que tous les deux semblent d'accord sur un point: il faut que l'utilisateur puisse avoir une idée précise et complète de la manière dont la fonction va utiliser les données dont elle dispose et du résultat qu'elle va donner.

Je ne crois en effet pas me tromper en disant que hegros admet que les TU ne sont d'aucune utilité du point de vue de l'utilisateur d'une fonction ou d'une classe

Seulement, vous semblez tous deux oublier une chose primordiale, lorsque vous énoncez vos vérités: elles sont inspirées par la réalité des restrictions imposées par le langage que vous utilisez.

Ce problème se pose bien sur lorsqu'il s'agit de déterminer la place des "cartouches", mais, dans une certaine mesure aussi lorsqu'il s'agit de déterminer si l'on décide d'obliger ou non l'utilisation du SISE...

Avec un langage qui ne présente aucun système de remontée d'erreur, dont on préfère (programmation séquentielle oblige) éviter les goto, etc, SISE est un choix qui peut se défendre (mais qui trouve autant de détracteurs que de défenseurs)...

Avec un langage qui propose un système cohérent de remontée des erreurs, SISE perd tout son attrait (ou, au moins, une grande partie de son attrait)

Ainsi, hegros énonce avec raison le fait que comme le code source est indisponible en C# ou en java, il n'y a - a priori - aucune raison de mettre cette description de fonction dans le code source, et qu'elle devrait se trouver "ailleurs".

De son coté, gl se base sans doute sur le fait qu'il est souvent beaucoup plus facile d'ouvrir le fichier d'en-tête (*.h / *.hpp), de faire une recherche dans ce fichier pour trouver la fonction qui nous intéresse et de lire le cartouche qui se trouve juste au dessus, plutôt que de devoir faire la recherche sur l'ensemble de la documentation générée automatiquement (du moins, à titre perso, je décide souvent d'agir de la sorte... principalement parce que je n'ai pas forcément envie de générer la doc en question )

Alors, posons nous un peu la question de savoir si la présence (ou non) de ce cartouche rend notre code sale

Le cartouche est peut être inutile si on travaille en C# ou en java, et sera donc plus ou moins intelligemment placé dans un fichier à part (si ce n'est que cela apporte la difficulté supplémentaire de devoir ouvrir un autre fichier pour modifier la documentation ), mais il est à une position finalement tout à fait cohérente en C ou en C++

De plus, j'ai le sentiment que tout le monde est d'accord avec le fait qu'un "code propre" est, avant tout, un code "facilement compréhensible par la personne qui l'utilise"...

Mais, de ce point de vue, et si on accepte l'idée que le fichier d'en-tête servira souvent de "base de compréhension" à l'utilisateur d'une fonction ou d'une classe, il reste tout à fait cohérent de dire que le cartouche rajoute à la propreté du code, et que la meilleure place que l'on puisse lui trouver est bel et bien dans le fichier d'en-tête

Pour ce qui concerne les commentaires "intra fonctions" maintenant...

Je me rappelle clairement avoir lu un livre à l'époque (pas si lointaine que cela) qui n'hésitait pas à énoncer la règle, tout à fait arbitraire, selon laquelle un code devrait être composé au minimum de... 1/3 de commentaires, le tout, entouré des autres règles couramment admises d'une instruction par ligne, de l'application d'une politique d'indentation stricte et du choix opportun des noms de fonctions / de variables...

Et j'étais farouchement opposé à cette "limite inférieure arbitraire": il n'y avait, à mon sens, aucune raison d'obliger à avoir un tiers de commentaires si un quart, un dixième ou même un centième suffisait...
Hegros dit en substance:

Grâce aux nom auto-documentés, au tests unitaires et au refactoring, il devient tout à fait inutile de rajouter des commentaires dans le code

(oui, je sais, tu es un peu plus nuancé )

Mais je voudrais alors lui poser la question de savoir sur quoi il va baser sa décision de refactorer ou de mettre ses tests unitaires à jour

• Sur les documents de conception Encore faut il qu'il s'agisse d'une erreur de conception
• Sur un système de "remontée de bug" Au mieux, tu sauras quelle fonction pose problème... Mais est-ce un problème algorithmique "pur" (tu n'a simplement pas choisi la "bonne" logique à suivre) ou est-ce un problème d'implémentation de l'algorithme (la logique à suivre est bonne, mais pas la manière dont elle a été implémentée)
• De manière arbitraire mais, alors, quel sera ton axe de décision
• d'une autre manière

Quand on pense qu'un code est beaucoup plus souvent lu / étudié / revu qu'il n'est écrit / modifié.

Quand on pense qu'un petit commentaire bien placé dans le code (et, par code, j'entends tout ce qui, d'une manière ou d'une autre, peut être en relation avec le code ) permet, non seulement, de se faire une idée de "où ca coince", mais aussi de "pourquoi ca coince", je me dis que les quelques secondes utilisées pour l'écrire sont réellement bien investies

A titre personnel, j'estime que toutes les règles trop strictes ou trop "pointilleuses" devraient être envisagées avec une extrême suspicion...

Je n'ai aucun problème à énoncer ou à suivre une règle proche de

choisissez une politique d'indentation et respectez la tout au long du projet

car elle n'impose absolument pas la politique d'indentation

Je comprend qu'un écrit "déconseille", "limite", "restreigne au mieux" ou au contraire "conseille fortement" certains usages, tant il est vrai qu'il faut prendre ses décisions à bon escient.

Par contre, dés que j'entends des termes comme "interdiction","... prohibé(e)(s)", "interdit", "obligation", ... quand on parle de programmation, j'ai peur

[Garulfo]

C'est pourtant clair [...](expérience personnelle)

Merci pour la réécriture c'est plus clair

Oui le code est un livrable et conceptuellement cela te pose un probléme de le voir comme un document ? c'est finalement un .cpp ou .java

Ce n'est pas la référence de code à quoi j'imaginais mais le produit de l'activité d'implémentation/programmation et non de la conception.

En même temps ma plus grande expérience c'est dans le domaine de la production industriel...

Oui ce n'est pas un document. C'est un produit au même titre que l'exécutable. Les documents forment… la documentation. Le code est documenté (parfois par lui même) mais ne documente rien. D'un point de vue GL, la documentation du code est très différente du signifiant du code: elle dit ce qu'il faut faire et non ce qui est fait. Alors que le code ne fait que dire ce qui est fait. D'où l'obligation d'avoir une documentation qui n'est pas le code. Ce dernier ne pourra jamais indiquer ce qui doit être fait. La raison de rajouter ce pourquoi est à rechercher dans les besoins de tracabilité de la conception dans le code.

Maintenant on se rejoint tous d'une manière où d'une autre. Car si je fais cette précision, il reste que c'est une subtilité qui n'a pas lieu d'être si on se comprends. Dans l'ensemble on dit tous qu'il faut une forme de documentation de toute façon. On dit tous qu'il faut qu'elle soit une aide et non un frein. Selon le projet et la méthode choisie elle peut avoir une forme différente, mais elle est toujours là. Il y a beaucoup de blahblah ici pour finalement dire ça non ?

Je suis un adepte du code qui s'auto-documente. Mais il reste des petits morceaux de commentaires nécessaires qui documente ce que le code ne peut documenter de lui-même.

[benwit]

Je comprend qu'un écrit "déconseille", "limite", "restreigne au mieux" ou au contraire "conseille fortement" certains usages, tant il est vrai qu'il faut prendre ses décisions à bon escient.

Par contre, dés que j'entends des termes comme "interdiction","... prohibé(e)(s)", "interdit", "obligation", ... quand on parle de programmation, j'ai peur

+1
Un peu de bon sens, de pragmatisme et de liberté

[gl]

Il est illusoire de se baser sur des outils externes pour la pérennité et le traçage d'un logiciel....

C'est une bonne stratégie à court terme, mais c'est totalement illusoire sur un moyen ou long terme (supérieur à 5 ou 7 ans).

Non, ce n'est pas illusoire et ça peut très bien fonctionner. Toutefois comme je l'ai préalablement dit et je le répète, cela fonctionne bien dans mon contexte, je ne prétends que cela soit facilement transposable.

Quant-à la durée, j'ai déjà travaillé avec des projets qui sont sous gestion de conf depuis une dizaine d'année.
C'est plutôt dans les projets sans aucune gestion de conf que l'historique a été perdu (suppression de commentaire jugé inutile, modification à l'intérieur du modification qui fait que plus personne ne sait ce qui a été réellement modifié la première fois, etc.)

Ceci étant ce n'est pas forcément très grave de perdre l'historique après 5 ou 6 ans. Dans les différents projets sur lesquels j'ai travaillé, je ne connais personne qui ait eu besoin de remonter aussi loin dans l'historique.

(et que le choix soit de ta part, tu te mets le doigt dans l'oeil.. C'est une organisation qui décide, et tu n'as pas (souvent) ton mot à dire.. Et si tu changes d'organisation, c'est pire.. Et quand le matériel de sauvegarde change, c'est aussi pire...)

Non effectivement je n'ai pas le pouvoir de décision, mais généralement on me demande quand même mon avis.

En outre, j'ose espérer (et ce fut toujours le cas pour l'instant) que le changement n'est pas effectué du jour au lendemain et qu'un plan de migration est mis en place.

Si tu pars tu principe que quelqu'un va décider du jour au lendemain de changer quelque chose sans aucune gestion de la migration, il y a tellement d'autres problèmes potentiels plus graves que la gestion de conf qui se profile à l'horizon (en vrac bande de sauvegarde mise à la poubelle parce que le système de sauvegarde a été changé, remplacement des postes de travail la nuit sans récupération des données, changement du système cible sans prévenir personne, etc.).

[gl]

J'ai dernièrement subit la refactorisation par un nouveau qui venait d'arriver

Un code semblable à

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle ...)
{
code 1
};
 if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle...)
{
code 2
};
if((age>25 && age <65 && domicile="BELGIQUE") || activationManuelle...)
{
code 3;
};

est devenu entre ses mains

Code :

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

1
2
3
4
5
6
7
if(verifierPermission(...))
{
code 1
code 2
code 3
}

Certes le premier code n'est pas ce que j'appellerais un code propre mais les 3 tests représentent 3 conditions fixées par une ordonnance légale qui par hasard étaient à ce moment là identique. Lorsque l'un d'elles a changer, cela a été très amusant pour revenir en arrière.

Donc factoriser oui quand c'est possible; nettoyer le code, parfait. Il faut juste garder en tête que ceux qui ont codé avant nous (qu'il y ait 15 ans ou 15 jours) ne sont pas moins bons que nous et qu'il existe peut-être des raisons qui les ont amené à faire ces choix.

C'est typiquement, un cas où les vérifications auraient du être faites dans des fonction avec un nom explicite (un peu comme verifierPermission() mais décliner trois fois) avec un petit commentaire pour explique que oui il y a trois fois la même fonction avec un nom différent, mais c'est normal car ceci ou cela.

En outre un minimum de connaissance du domaine fonctionnel par l'auteur de la modification aurait sans doute permis d'éviter cette erreur.

[gl]

je n'ai pas lu la dernière page, mais j'ai lu une grande partie du débat qui porte sur les "commentaire de documentation de fonction", et j'ai l'impression que le gros du problème vient surtout du langage de référence des intervenants

En effet, gl se base principalement sur le fait qu'il utilise systématiquement deux fichiers distincts d'en-tête et d'implémentation séparés (*.c / *.cpp et *.h / *.hpp) pour créer une unité de compilation pour justifier le fait que le commentaire "cartouche de fonction" ou "d'en-tête" doit se trouver juste au dessus de la déclaration de la fonction,

Tout à fait.

Même si l'utilité de la pratique peut être étendu à tout les cas de figure ou le source est disponible par l'utilisateur (je pense notamment aux langages interprétés et aux projets open-source).

alors que hegros semble avoir une approche plus basée sur le C# ou le java, où la déclaration et l'implémentation se font dans un seul et même fichier, qui n'est au demeurant pas ou plus disponible pour l'utilisateur de la classe créée.

Dans ce cas de figure l'intégration de la documentation dans l'environnement d'édition est effectivement perdu. Par contre l'intérêt des commentaires pour générer une documentation cohérente et à jour est conservé.
C'est d'ailleurs me semble-t-il Java qui a popularisé, si ce n'est introduit, ce concept avec la Javadoc.

Seulement, vous semblez tous deux oublier une chose primordiale, lorsque vous énoncez vos vérités: elles sont inspirées par la réalité des restrictions imposées par le langage que vous utilisez.

Tout à fait. Même si certaines pratiques sans être totalement universelle se transpose très bien à une nombre très important de langages.

De son coté, gl se base sans doute sur le fait qu'il est souvent beaucoup plus facile d'ouvrir le fichier d'en-tête (*.h / *.hpp), de faire une recherche dans ce fichier pour trouver la fonction qui nous intéresse et de lire le cartouche qui se trouve juste au dessus, plutôt que de devoir faire la recherche sur l'ensemble de la documentation générée automatiquement.

Pas tout à fait, l'intégration de la documentation dans l'environnement de travail (que ce soit par usage de la fonction Rechercher ou par des fonctionnalité plus avancées de l'éditeur - fonction "Go to declaration", affichage contextuel du cartouche de commentaire dans une pop-up ou autre) n'est qu'un des points qui me pousse à commenter mes fonctions.

Le besoin de générer une documentation cohérente avec le code et à jour est une autre raison qui elle à un champ d'application plus important (Java et C# sont bien concernés ici).

Le cartouche est peut être inutile si on travaille en C# ou en java, et sera donc plus ou moins intelligemment placé dans un fichier à part (si ce n'est que cela apporte la difficulté supplémentaire de devoir ouvrir un autre fichier pour modifier la documentation ), mais il est à une position finalement tout à fait cohérente en C ou en C++

cf. ma réponse ci-dessus.

Pour ce qui concerne les commentaires "intra fonctions" maintenant...

Je me rappelle clairement avoir lu un livre à l'époque (pas si lointaine que cela) qui n'hésitait pas à énoncer la règle, tout à fait arbitraire, selon laquelle un code devrait être composé au minimum de... 1/3 de commentaires, le tout, entouré des autres règles couramment admises d'une instruction par ligne, de l'application d'une politique d'indentation stricte et du choix opportun des noms de fonctions / de variables...

Et j'étais farouchement opposé à cette "limite inférieure arbitraire": il n'y avait, à mon sens, aucune raison d'obliger à avoir un tiers de commentaires si un quart, un dixième ou même un centième suffisait...

Effectivement c'est une règle étrange, pour ne pas dire stupide.

A titre personnel, j'estime que toutes les règles trop strictes ou trop "pointilleuses" devraient être envisagées avec une extrême suspicion...

Je comprend qu'un écrit "déconseille", "limite", "restreigne au mieux" ou au contraire "conseille fortement" certains usages, tant il est vrai qu'il faut prendre ses décisions à bon escient.

Par contre, dés que j'entends des termes comme "interdiction","... prohibé(e)(s)", "interdit", "obligation", ... quand on parle de programmation, j'ai peur

100% d'accord. De mon point de vue une norme de programmation doit plutôt

• Soit donner des tendances, un but à atteindre plus qu'une règle absolu.
• Soit donner des règles absolues en précisant que les règles peuvent être enfreintes lorsqu'il existe une bonne raison de le faire et à condition de documenter correctement cette infraction.

Je n'ai aucun problème à énoncer ou à suivre une règle proche de

choisissez une politique d'indentation et respectez la tout au long du projet

car elle n'impose absolument pas la politique d'indentation

Etrangement, les règles de présentation (c'est à dire espace/tabulation pour l'indentation, taille de l'indentation, position des délimiteurs, CamelCase vs underscore) sont les seuls cas où je conçoit que l'on puisse fixer arbitrairement un choix afin de garantir à la fois une uniformité au sein d'un projet (surtout dans le cas d'équipe importante ou fortement dispersée pour être sur que tous font le même "choix") mais aussi au sein d'une structure (entreprise, service, association ou autre).

Laissez le choix, même lorsque les personnes se tiennent à leurs choix, risque d'aboutir à une hétérogénéité qui n'est pas toujours acceptable.

Bien que le problème ne se pose pas réellement sur l'indentation ou la position des délimiteurs, puisqu'il est relativement simple de retoucher ces points à postériori et uniformiser automatiquement le tout (de nombreux langages disposent de tels outils).