Dans le grand débat : Qu'est-ce qu'un code "propre" selon vous ?, tous le monde n'est pas d'accord sur le fait que commenter son code rende celui plus exploitable/lisible.
Quel est votre avis ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui
Non
Discussion :
Faut-il commenter son code source pour le rendre plus lisible et maintenable ?
Dans le grand débat : Qu'est-ce qu'un code "propre" selon vous ?, tous le monde n'est pas d'accord sur le fait que commenter son code rende celui plus exploitable/lisible.
Quel est votre avis ?
En fait ça ne se discute pas trop. La question n'est pas de savoir s'il faut commenter, mais plutôt comment et en quelle quantité. Il peut peut-être y avoir des cas extrêmement exceptionnel… menfinbon il me semble que même là les commentaires restent pertinents.
pour moi oui mais avec modération ....
lors de cas de test bien tordu, issu du métier par exemple il est nécessaire d'avoir une petite note pour nous éclairer
C'est un peu abuser ce sondage. Telle qu'est posée la question, je vois difficilement comment on peut répondre non.
Pour une démonstration/exemple/tutoriel/cours/etc oui il faut commenter le code c'est évident et vraiment utile.
En production par contre c'est différent. On ne peut plus appeler cela un commentaire puisqu'on s'en sert aussi pour l'automatisation des tests et/ou de la documentation voir d'autres choses encore.
Soit cela sonne comme 'complétement déréglée' lorsque chacun mets à sa sauce le type de commentaire qu'il lui fait plaisir et la qualité du document de code se dégrade avec le temps.
Qui n'a jamais lu un commentaire incompréhensible voir douteux sur un projet dans lequel il est entré et qui existe depuis belle lurette ? Tout le monde ? Alors il y a une immensité de code commenté qui ne serve à rien(probablement des pétagigaoctets)
J'ai donc répondu non.
Je ne connais pas un seul sondage non orientéEnvoyé par white_tentacle
C'est un peu abuser ce sondage.
Ce qu'il veut dire c'est que tu n'expliques pas ton sondage ni ne donne ton propre avis, juste un lien sur n pages discuté depuis n mois.Je ne connais pas un seul sondage non orienté
Et franchement répondre oui ou non à ce genre de question c'est effectivement un mauvais sondage
Mon avis est simple à déduire, tout le monde a répondu oui, sauf toi!Ce qu'il veut dire c'est que tu n'expliques pas ton sondage ni ne donne ton propre avis, juste un lien sur n pages discuté depuis n mois.
Et franchement répondre oui ou non à ce genre de question c'est effectivement un mauvais sondage
Je suis d'accord que la question est mal posée, mais hélas on ne peut pas la changer quand le sondage est lancé, il faudra vivre avec...
Ah oui et puis quand la SOFRES m'appelle, ils me donnent rarement leur avis
Forcément si tu compares ton niveau de sondage à ceux de la SOFRES...
Quelque soit le niveau, un sondage reste un sondage, sinon ça s'appelle pas un sondage...
C'est pas la SOFRES ici c'est DEVELOPPEZ. Hors ton sondage est très pauvre par rapport aux autres concernant ce qui en est attendu.
Bref, je vous laisse vous amuser avec...
Merci!
Rien ne vous empêche de recréer un sondage plus exhaustif si vous pensez que celui-ci n'est pas adéquat.
On fera le nécessaire pour supprimer celui là.
Non ce n'est pas différent.
On continue à mettre des commentaires. Que ce soit des cartouches d'entête, des références à la conception ou des indications à un oracle, il faut en mettre.
Bien sûr si tu n'appelles pas « commentaires » ce qui est mis en commentaires pour documenter le code… et que pour toi un commentaire c'est juste une remarque non pertinente et inutile… bin tu as raison. Menfinbon, c'est tiré par les cheveux.
Non Garulfo. Parce qu'on peut te demander comme développeur d'écrire un programme pour lequel la cartouche de commentaire est déjà écrite soit il n'a pas à l'écrire mais bien à se documenter d'abord.
Ensuite c'est une question de process l'automatisation de la documentation peut se faire de la manière qu'on souhaite soit en rétro soit en merge soit par une chaîne de compilation comme l'exposé dans la discution gl.
M'enfin j'utilise moi même des cartouches de commentaires pour mes programmes parce que les éditeurs les intégre bien et ne propose pas d'autres choses c'est tout.
Après un commentaire cela reste un commentaire après tout qui a vraiment le temps de tous les lire ?
La justification qui me fait rire c'est commentez pour expliquer une partie obscure J'appelle cela plus une prouesse qu'un commentaire
Hum. C'est certain qu'avec ce genre d'arguments, le débat va avancer...!
"Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
---------------
Mes billets de blog sur DVP
Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
Pensez à utiliser les tableaux structurés. Ils vous simplifieront la vie, tant en Excel qu'en VBA ==> mon tuto
Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
---------------
Normal sur 500 000 lignes de code avec 30% de commentaire cela fait combien de livre à lire ? Je ne vois pas comment on pourrait tous les lire lorsque tu es sur n projets...
Et donc le code est commenté… encore une fois, la question n'est pas « faut-il des commentaires ?» — car il me semble que personne de sérieux n'a jamais préconisé de ne pas faire de commentaire, sinon j'aimerais voir une référence — mais plutôt « comment les faire ? » Si qqun les a fait pour toi alors le code a bien été commenté.
C'est ridicule comme remarque.
Ce n'est pas moi qui ait dit ça... cependant ça peut arriver. Malgré tout le crédit que j'accorde au code qui s'auto-documente, il peut rester des morceaux obscurs. Mais je pense que tu n'as toujours pas saisi qu'un commentaire est avant tout là pour d'autre raison qu'expliquer ce que celui qui a écrit le code a fait. Le commentaire s'utilise surtout pour indiquer ce qu'on doit faire et non ce qui a été fait. Si tu écris ton commentaire a posteriori alors tu as tendance à paraphraser dans ton commentaire ce que tu as fait dans ton code. Et là, c'est vrai que ton commentaire perd grandement de son intérêt, surtout si le code est bien écrit et pensé. Tant que tu n'auras pas saisi les problématiques de traçabilité, la nécessité de la gestion des besoins et autres problèmes en GL, il me semble que tu ne comprendras pas — ou que tu ne voudras pas comprendre même — l'intérêt et le but d'un commentaire.La justification qui me fait rire c'est commentez pour expliquer une partie obscure J'appelle cela plus une prouesse qu'un commentaire
Aucun rapport. Tu n'écris pas un commentaire pour qu'un développeur les lise comme dans un livre. Encore une fois, tu ne comprends visiblement pas l'intérêt et le but d'un commentaire. Je te dirais bien de retourner un peu sur les bancs de l'école mais probablement que quelques réflexions et quelques bonnes lectures devraient suffire si tu fais un effort.
Répondre avec citation
Partager