C'est pour cette raison que je disais que tout dépend du contexte. Parfois elles sont utiles car elles contribuent a la lisibilité du code parfois ça sert à rien exemple
Code:
1
2 boolean test=false; //initialisation de la variable test
Version imprimable
Effectivement, il faut faire attention. Mais si pour test c'est trivlal, de meme qu'ici, le commentaire est facultatif :
il ne faut pas oublier que souvent, apres quelques mois, les noms de variables ne semblent plus aussi explicite qu'ils ne l'etaient. Ainsi :Code:
1
2 int i ; /* loop counter */
Dans les deux cas, tu as un nom explicite, mais dans le second cas, le commentaire est utile. Du coup, dans le doute, j'en mets partout.Code:
1
2 FILE * config_file ; /* configuration file */ FILE * archive_file ; /* file to archive only the correct data */
Tu veux qu'on s'use les doigts toi malheureux :cry:
Non tu ne 'aurais pas fait. Pour au moins 2 raisons :
- Tous, codeurs, autant que nous somme, nous pouvons, hors contexte, avoir de belles théories sur le nommage des variables. Mais dans la réalité du code, nous allons tous vers des variables aux noms relativement courts. Normal quand on les tapent 50 fois et plus par logiciel.
Et au delà du fait qu'un code avec des noms de variables trop long devient très rapidement extrêmement pénible à lire.
- Pour toi, comme pour nous tous, au moment de choisir le nom de la variable, dans le contexte du développement, avec toute l'architecture et la conception du logiciel dans la tête, archive_file est un nom correct et suffisamment explicite pour une variable représentant un fichier archivant les données fussent-elles seulement les correctes. D'autant plus si c'est le seul fichier d'archive présent dans le logiciel.
Mais qu'en est-il 6 mois, 2 ans, 5 ans après ?
Même 2 ans après, archive_file est toujours suffisamment explicite pour désigner un fichier d'archive et c'est ce qu'on lui demande.
Mais la notion de "seulement les données correctes" est oubliée depuis longtemps. Dans la mesure ou cette information n'est pas forcément intrinsèquement nécessaire à une première lecture rapide du code, le commentaire se justifie totalement dans ce cas.
Pour mon cas j'ai besoin seulement de taper une fois le nom de ma variable en entier car de nos jour, il existe l'auto complétion dans la plupart des IDE. J'ai pas dis que archive_file n'est pas explicite mais plutôt qu'il reste vague. Et vraiment choisir entre le commentaire de plus ou un nom de variable long et parlant, Perso je choisis le deuxième.
J'avoue ne pas très bien saisir l'intérêt de cette nouvelle discussion alors qu'il existe plusieurs (dont certains longs, et/ou dans les Best-Of) débats sur le forum Débats spécialsé sur ce sujet :
Faut-il commenter son code-source pour le rendre plus lisible et maintenable ?
De l'intérêt des commentaires
Un code bien commenté remplace-t-il une documentation (+ gestion doc entreprise)
Projets informatiques : les bonnes pratiques
:roll:
C'est ce que l'on appelle en langage journalistique un marronnier, un sujet de peu d’intérêt mais qui revient régulièrement sur le devant de la scène.
Parce que bien que tout ait été dit sur le sujet, depuis longtemps et à plusieurs reprises, le débat n'est jamais clos et se trouve toujours quelqu'un pour avoir quelque chose à dire et donc relancer le sujet.
J'ai ri (mais vu le -1 accolé au message, quelqu'un d'autre n'a pas fait de même) :lol:
Les commentaires, ça dépend beaucoup de chacun, de la complexité des projets et du code, de la qualité d'une documentation pouvant être fourni, du langage utilisé (le code doit être clair, mais en assembleur par exemple, mieux vaut ne pas compter sur le code !)
Je ne vois pas du tout là....... :aie:Citation:
Ah ben tiens, en info on a aussi un terme bien velu pour ça...
Y paraît même qu'il ne faut pas le nourrir.
Perso, je déclare des variables, fonctions .. avec des noms qui veulent dire quelquechose.
Après le commentaire, c'est quand je fais un truc un peu sioux ou alors il y a une condition particulière que je risque d'oublier
Mais dasn tous les cas je l'utilise avec parcimonie
S'agissant d'un débat , je dirais de toutes évidences que je suis POUR les commentaires dans le code.
==> En expérience dans ma vie de programmeur en formation j'ai eu à développer et superviser des micro-projets, macro-projets (en cours d’exécution) et vraiment les commentaires dans le code m'ont tellement aidé à me retrouver dans des centaines de milliers de ligne de code.Certes on a l'impression que c'est ennuyeux et retardant dans l'objectif préfixé mais en réalité quand vous codez des millions de lignes de code et vous faites deux jours ou plus , il est difficile de se retrouver et de comprendre l'idée émise , l'esprit dans lequel vous vous étiez mis,le contexte où vous vous trouviez pendant l'écrit du code la dernière fois.
==> De plus , l'Edition du code est une OEUVRE D'ART, qui se doit d'être éprouvé , admiré et parfois utilisée en cas d'usage libre.Ceci dit que votre code n'est pas seulement pour vous-même mais doit être fait de telle sorte qu'il soit compris par d'autres programmeurs.
==> La compréhension du code doit donc être étayé durant l'édition à travers les commentaires brefs et precis.
==> Votre code doit être VIVANT
:ccool: