Discussion :

[urbalk]

Bonjour,

la programmation nous amméne a placer beaucoup de remarque dans nos codes:
// , /* en php
<!-- en html
etc...
Hors mis la taille du fichier existe-il d'autres raisons pour enlevé ou laisser ces remarques ??

en gros vaut-il mieux les laissées ou les enlevées ?

merci

[JMLLB]

De manière générale en programmation on n'utilise pas exactement les commentaires de la même façon pendant les phases de conception, debuggage et maintenance.

Pendant la conception c'est principalement pour décrire les fonctionnalités.
Pendant le debuggage c'est plutot pour debrayer des parties de code, marquer des points douteux, signer un correctif.
Pendant la maintenance c'est pour décrire les corrections/ajouts/retraits et les signer.

Si tu utilises un outil de gestion de configuration tu peux te passer de commentaire de signature ( ex: //JM.Dupond: 17/03/2001). Dans le cas contraire ca peut être utile.

Pour le code débrayé, ainsi que pour les remarques folkloriques: une fois en phase de maintenance ça fait franchement clown!

Pour les commentaires explicatifs, ils sont indispensables lors de toutes les phases quitte à les compléter à postériori. C'est la seule doc qui ne se sera jamais perdue (sauf si on pert le code mais là...)

[souviron34]

D'accord avec JMLBB, mais j'insisterais encore plus :

IL EST INDISPENSABLE DE GARDER BEAUCOUP DE COMMENTAIRES (de description, évidemment, pas des "faut que j'aille prendre un café".. ) dans un code.

Tu n'es pas sûr (et même quasi-certain du contraire) que ce n'est pas toi qui feras la maintenance, et même si c'était le cas, il faut avoir les commentaires pour se souvenir de ce qu'on voulait faire).

Comme le dit JMLBB, ils ont des utilités diffrentes suivant les phases, cependant, mis à part les commentaires de debug, il FAUT les laisser. Que ce soit pour l'historique ou pour la conception, ou la maintenance.

Une nuance cependant à son propos :

...Si tu utilises un outil de gestion de configuration tu peux te passer de commentaire de signature ( ex: //JM.Dupond: 17/03/2001). Dans le cas contraire ca peut être utile.
...

Même avec un outil de gestion de configuration, en général le commentaire de signature (et/ou remarque d'insertion de modification) sera inséré en tête du fichier.

Je conseille vivement d'entourer toute modification d'un début avec

// BEGIN JM.Dupond : 17/03/2001

et

// END JM.Dupond : 17/03/2001

dans le code, à l'endroit de la modification, avec éventuellement le détail de la modif en commentaire en dessous du BEGIN.

[urbalk]

Bonjour,

Merci de toutes vos réponses.

En faite ma question était mal formulée...

Faut-il garder les commentaires sur le fichiers en production ?

Concernant la partie dev et debug en effet j'ai toujours gardé la totalité de mes remarques.

encore merci.

[Anthony.Desvernois]

Oui sauf si :

- tu ne comptes pas modifier ton code ni le debugger
- tu garde une copie du code commente

[souviron34]

Faut-il garder les commentaires sur le fichiers en production ?

OUI car en quoi tes fichiers en production seraient-ils alourdis par les commentaires ? (sauf si ce sont des html, xml, etc.., c'est-à dire format texte) . Pour mémoire les commentaires ne font pas partie d'un code compilé.

A part pour des questions de "secret commercial" où tu ne veux pas laisser à n'importe qui le soin de comprendre par exemple un format de donnée ou un algo, je ne vois pas bien l'intérêt (et par contre je vois les inconvénients) de gérer 2 versions avec juste les commentaires en moins.

[Anthony.Desvernois]

Deux interets :

- gain de place (sur un gros projet ca peut faire beaucoup)
- le code peut etre lu par une tierce personne sur la machine de prod

Evidement c'est aussi plus contraignant de gerer deux version, quoique avec un scripts sed de base, ca se fait.

[JMLLB]

Même avec un outil de gestion de configuration, en général le commentaire de signature (et/ou remarque d'insertion de modification) sera inséré en tête du fichier.

Je conseille vivement d'entourer toute modification d'un début avec

// BEGIN JM.Dupond : 17/03/2001

et

// END JM.Dupond : 17/03/2001

dans le code, à l'endroit de la modification, avec éventuellement le détail de la modif en commentaire en dessous du BEGIN.

Un bon outil de gestion de conf te permet de faire des diffs entre deux versions.
Lorsque plusieurs modifs successives se croisent sur la même portion de code, sans des coups de diff tu peux pas devinner grand-chose.

Ceci étant dit, un marquage n'alourdit pas les autres commentaires et pour le cas ou l'on perd l'historique, on est quand même bien content de les avoir sur une version donnée (généralement sauvegardée sur un cd avant que la station ne brûle et qu'on se rende compte que les procedures de sauvegarde n'étaient pas respectées ).

Perso, je vire tout les commentaires de marquage avant de livrer la première version et je les garde après. Sauf s'il y a eu des changements dans l'équipe.

[Jedai]

Ca me rappelle la AOP (non, pas l'Aspect Oriented) votre discussion là... Avec un gestionnaire de version dont on se sert correctement les commentaires de marquage sont au mieux superflus, au pire très lourds ! (Les outils permettent de visualiser les modifs précisément en mettant en vis-à-vis les deux versions, et l'explication des modifs ne devrait pas être dans la version finale (ça n'aide pas à la comprendre pour quelqu'un qui ne connait pas les versions précédentes), mais dans le commentaire de diff)
Ca ne veut pas dire que je n'ai pas fait ça moi-même, simplement je n'ai pas l'impression qu'il y ait de réels arguments en faveur de ce type de commentaires (le problème de disque ne me convint pas : il faut de toute façon faire des sauvegardes régulières)

--
Jedaï

[JMLLB]

Deux interets :

- gain de place (sur un gros projet ca peut faire beaucoup)
- le code peut etre lu par une tierce personne sur la machine de prod

Evidement c'est aussi plus contraignant de gerer deux version, quoique avec un scripts sed de base, ca se fait.

Pour ce qui est des langages compilés et interprétés:
gain de place? en multipliant le code par 2? là je ne vois pas!

pour le côté confidentialité (j'aurai dit paranoïa), ton code non compilé est seulement sur ta machine de développement. Sur ta cible tu n'as que le code compilé.
Alors de toutes manière si un tiers hostile a accès à la machine de dev, avoir deux versions différentes n'a aucun intérêt.
C'est déjà suffisament simple de se planter dans une équipe d'une dizaine de personnes avec autant de versions différentes sans aller chercher les coups.

[Marc Lussac]

Non seulement c'est nécessaire si ce code doit être maintenu par d'autres, mais ca te sera utile à toi si tu doit le maintenir plus tard et que tu aura tout oublié

[droggo]

Jai,

Deux interets :

- gain de place (sur un gros projet ca peut faire beaucoup)
- le code peut etre lu par une tierce personne sur la machine de prod

Evidement c'est aussi plus contraignant de gerer deux version, quoique avec un scripts sed de base, ca se fait.

Je n'appellerais pas "gain de place" le fait de maintenir 2 versions d'un fichier.
Pour moi, c'est plutôt "perte de place", non ?

Sans parler de la contrainte de maintenir ces 2 versions, comme tu le dis si bien.

Et si le code peut-être lu, la présence ou non de commentaires ne changera rien si quelqu'un veut copier.

[Anthony.Desvernois]

Gain de place sur la machine de prod.
Evidement la version avec code tu la garde sur la machine de dev/test.

Et sinon crois moi certains code sans les commentaires pour les pomper et les adapter bon courage

[Marc Lussac]

Il y à pas un outil ou un EDI qui permer de virer les commentaires automatiquement pour la mise en prod (mais tu garde le source avec les commentaires). Et je supose que les logiciels serveurs ou cache pour php font aussi ca automatiquement (c'est à dire que si tu as installé un cache pour php sur le serveur, à l'éxécution il ne passe plus par les commentaires, vu qu'il éxécute une espèce de pcode).

Déjà à mon époque préhistorique les compilos fesait ca, ca doit bien exister pour php.

[Anthony.Desvernois]

Oui et puis faire un script qui le fait c'est pas la mort non plus

[souviron34]

je répète juste que pour un langage compilé LES COMMENTAIRES NE SONT PAS DANS l'EXECUTABLE...

La meilleure preuve en est d'essayer de déassembler du code... Bonne chance...

Les seules informations POUVANT y figurer sont celles de debug, si les flags de debugs ont été mis à la compil. Et là un "strip" permet de les enlever du binaire pour livraison. Et là oui on gagne de la place. Mais aucunement sur les commentaires..

Quant aux fichiers textes (html, xml, (php je ne connais pas)), là oui tu peux vouloir les enlever..

[Anthony.Desvernois]

La en l'occurence il parle de PHP et d'HTML, ce qui est pas du genre compile

[Caine]

Dans le cadre de langage compilé les commentaires ne servent qu'au programmeurs et concepteurs.

Qu'entends tu par une version de prod? Pour un programme, la version de prod est soit une librairie, dll et consorts, soit un exécutable.

évidemment, sauf si tu livres des sources s'intégrant dans un projet externe. Dans ce cas, d'ailleurs, à moins d'une exigence client obscure, il vaut mieux laisser les commentaires.

Le seul cas ou une version sans commentaire s'est avéré utile c'est pour de la relecture de code avec recherche par regexp...la redondance avec les commentaires doxygen est souvent très pénible et même en Perl, ignorer les commentaires pose des difficultés.

Mais c'est vraiment le seul cas que je vois de suppression souhaitable des comments.

Pour les langages à balise ou interprétés, là c'est souvent une question de "conserver" une connaissance propriétaire du code. La version mise en production est j'imagine très allégée en commentaire.

Ceci dit, il y a la propriété intellectuelle qui protège le code je pense.

[Marc Lussac]

Mais PHP c'est effectivement pseudo compilé sur les serveurs spécialisé php et par les caches php.

Pour html les outils pour compresser le code et virer les commentaires ca existe aussi

[millie]

Si tu as du code que html, en général, c'est que ton application n'est pas très violente et qu'il n'est pas forcement utile d'avoir des commentaires.

Pour des applications web plus complexe, par exemple avec J2EE avec des pages JSP, il existe des commentaires particuliers (<%-- --%>) qui seront retirés lors de la compilation de la page JSP vers la servlet Java (bytecode qui ne contiendra évidemment pas de commentaire)