Commentaire ligne de code

[ayaflo]

Bonjour le forum,

Voilà ça fait peu de temps que je navigue sur ce forum qui m'a grandement aidé dans mes travaux professionnels et je me posais une petite question suite à une observation que j'ai pu faire sur mon lieu de travail. Dans mon entreprise nous commentons tous nos codes, ce qui nous permet de reprendre les codes des autres plus facilement dans le cas ou nous devons rêgler des problèmes ou faire évoluer des fichiers.

Donc ma question est la suivante :

Pourquoi la majeure partie des lignes de code qui sont postées ne comportent pas de commentaire ou même dans les fichiers que nous envoyons pour demander de l'aide?

Je ne dis pas que je le fais, mais je relève juste l'idée.

Ca pourrait aider les débutants à progresser assez vite et les utilisateurs à mieux comprendre les codes pour les adapter.

A+

 

[Robert]

Re : Commentaire ligne de code

Bonsoir le fil, bonsoir le forum,

J'ai pris par habitude de pratiquement toujours commenter et tester les codes que je soumets. Ça me demande un effort, parfois important, mais je le fais autant pour le demandeur que pour moi-même car je me suis rendu compte que j'apprenais et surtout je retenais mieux en le faisant.
Mais, comme le souligne le squale-en-chaleur (que je salue au passage), tu ne peux pas demander à tout le monde de le faire ! Je pense que tu ne te rends pas bien compte du degré d'implication de beaucoup de gens dans ce forum...

 

[Robert]

Re : Commentaire ligne de code

Bonsoir le fil, bonsoir le forum,

Damned voilà t'y que le squale à froid. Remarquez quand le squale à tort tout le monde descend (ou monte) mais c'est rare...

 

[Staple1600]

Re : Commentaire ligne de code

Bonsoir à tous


[avis personnel]
Au début de mes pérégrinations sur XLD (débutées en 2005), je faisais de belles pièces jointes, avec ou sans commentaires.
Parfois je poussais la chose jusqu'à créer une macro pour générer des données de test.
Bref je donnais beaucoup de mon temps libre sur XLD

Puis avec le temps; au bout d'un certain nombre de désillusions

- comme l'attitude parfois désinvolte
-comme ces questions demandant une réponse URGENTE
-comme ces questions du genre "Moi je veux" sans fichier exemple joint, laissant entendre que les membres du forum n'ont qu' a créer eux-même les fichier exemple
​

Bref, un jour j'ai pris le parti de ne plus joindre de pièce jointe (en tout cas de fichier Excel), de rarement commenter mon code, ou les formules.

En faisant cela, j'avais le secret espoir que cela entrainerait de la part de celui-ci qui posait une question sur XLD, une foultitude de questions demandant des précisions, des explications quand à mes propositions, bref un beau brin de curiosité.

J'observe la plupart du temps que le demandeur, bien embêté de ne pas trouver un fichier Excel dans mes réponses, ne prend plus le temps de mettre la main à la pâte, ne lis pas les consignes que je mets dans mes réponses, est très peu friand de la touche F1, utilise rarement le moteur de recherche du forum.

Mais tout espoir n'est pas perdu, car il y aussi des nouveaux membres qui sont restés curieux, et non consuméristes de solution clés en main , n’ayant requis de leur part comme seul effort que celui de rédigé leur question sur XLD.
[/avis personnel]

PS: Commenter le code VBA est bonne pratique , rédiger des questions précises (en ayant fait des recherches avant) accompagné d 'une PJ illustrant la difficulté rencontrée, l'est aussi.

Donc oui aux codes VBA commentés, "mais messieurs les anglais, tirez les premiers"...

Donnez nous des questions bien ficelées et ou l'on sente que le demandeur va s'impliquer dans la résolution de la question qu'il pose sur ce forum.

 

[ROGER2327]

Re : Commentaire ligne de code

Bonjour à tous

J'irai dans le même sens que celui de la plupart des messages précédents. Commentez proprement un code est quelquefois aussi long à réaliser que concevoir le code lui-même. On doit le faire systématiquement lorsque l'usage du code est professionnel. Mais cela se facture...
Dans le cadre de réponses bénévoles, on ne saurait avoir de telles exigences. Après un certain temps de pratique de ce forum, j'ai pris le parti de peu commenter mes propositions de code, quitte à ajouter des commentaires lorsque le demandeur s'intéresse vraiment à la proposition.
J'ai jadis été moins avare, mais, devant la désinvolture de certains demandeurs qui ne prennent pas même la peine de revenir voir s'il y a une réponse à leur question, j'estime inutile de commenter longuement un code.
Par ailleurs, il est souvent plus instructif de décortiquer un code brut que de lire un commentaire.
Si l'on veut une solution clef en main, sans le moindre effort et suffisamment commentée pour être facilement entretenue, on ne vient pas sur un forum d'entraide : on paye les service d'un professionnel. Mais ça, c'est de la théorie...

Par ailleurs, lorsqu'on passera moins de temps à traduire certaines questions en Français avant de commencer à y répondre, on aura plus de temps pour commenter. (J'espère que cette phrase ne me vaudra pas une bordée de réponses indignées...)
​

Bonne nuit !



ROGER2327
#6099

Hunyadi 29 Gidouille 139 (hunyadi gras - Nom d’Ubu - fête Suprême Seconde)
25 Messidor An CCXX, 0,5415h - pintade
2012-W28-5T01:17:59Z

 

[francedemo]

Re : Commentaire ligne de code

bonjour à tous,
idem que les commentaires ci-dessus
pour le paragraphe de Roger, j'ajouterai, en plus, qu'il m'est arrivé de ne pas répondre à une question (alors que je connaissais une solution) uniquement par ce que l'éditeur n'avait pas pris la peine de rédiger sa question avec le minimum de courtoisie (bonjour...) et de respect de la charte.
enfin, c'est pas trop grave, c'est un forum bénévole.
(on y voit souvent les mêmes...d'ailleurs )
à +

 

[Modeste geedee]

Re : Commentaire ligne de code

Bonsour®

Par ailleurs, il est souvent plus instructif de décortiquer un code brut que de lire un commentaire.

cependant écartant de fait l'implication du demandeur...
le commentaire d'un code est un sujet mouvant.

par expériences de mes débuts en programmation (langage machine et notament en APL®)
les codes étant interprétés ligne à ligne, l'objectif étaient de faire le plus compact et le plus rapide possible.
c'était l'époque des "one-liner"
les commentaires étaient systématiquement supprimés des programmes d'exploitation.
d'ou l'interet de nommer et typer correctement les variables et noms de proc
avec les langages compilés, les sources ont pu etre enrichies, l'executable n'étant plus du domaine du programmeur.

les commentaires...

structurels : il sont inutiles !ici début de boucle, fin de boucle, incrémentation etc... potasser la doc langage : point!

fonctionnels : le découpage modulaire et les cartouches d'identification devraient suffire à décrire les fonctions ainsi que les particularités...
la doc de réalisation écrite avant réalisation doit suffire !(cette étape s'appelle analyse et conception)

mais comme dit Roger : ça c'est la théorie...

par fainéantise, mouvance des spécifications, délais, rapièçage ont trouve de tout (programmation spaghetti)

j'ai même écris des procs pour restituer l'ordinogramme de programmes fonctionnels dans le but d'en corriger les specifications initiales (rétro-enginering)
bonjour les surprises (codes morts, redondants, inutiles, variantes)

plus pénélisant que l'absence de commentaire, la gestion des erreurs souvent incomplétes, mal intégrée, voire non sécurisante,plantage, résultats incohérents à inexpliqués.