Etes vous pour ou contre les commentaires dans le code - Page 3

omarcisses · 25/06/2012, 12h33

Citation:

Envoyé par gangsoleil

Et pourtant...

Qu'est-ce qui va plus vite ? Lire une phrase explicite, ou bien un code de 15 lignes explicite ?

Ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* Did the read went fine ? */
if (return_code == MY_RETURN_KO)
{
    bla bla
    bla bla
  
    appel de fonction de remplacement
   
    if (appel a merde la aussi)
    {
            bla bla erreur
            bla bla
    }

   fin du bla bla
}

Par ailleurs, dans les editeurs de code qui permettent de replier des parties de code, tu vois le commentaire, le if, et c'est tout. Tu n'as donc pas a deplier le code pour savoir ce qui est fait dedans.

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 :

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

1
2
boolean test=false; //initialisation de la variable test

gangsoleil · 25/06/2012, 12h52

Citation:

Envoyé par omarcisses

Code :

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

1
2
boolean test=false; //Initialize to false because result may not need to be tested

Effectivement, il faut faire attention. Mais si pour test c'est trivlal, de meme qu'ici, le commentaire est facultatif :

Code :

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

1
2
int i ; /* loop counter */

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 :

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

1
2
FILE * config_file ; /* configuration file */
FILE * archive_file ; /* file to archive only the correct data */

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.

omarcisses · 25/06/2012, 14h09

Citation:

Envoyé par gangsoleil

Code :

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

1
2
FILE * config_file ; /* configuration file */
FILE * archive_file ; /* file to archive only the correct data */

Parfaitement d'accord avec toi sauf que le nom de ta variable dans le deuxieme est assez vague. Moi j'aurais mis archrive_file_only_correct_data je pense que ce serais plus parlant

ManusDei · 25/06/2012, 14h29

Tu veux qu'on s'use les doigts toi malheureux

sevyc64 · 25/06/2012, 16h05

Citation:

Envoyé par omarcisses

Moi j'aurais mis archrive_file_only_correct_data je pense que ce serais plus parlant

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.

BenoitM · 25/06/2012, 16h15

Citation:

Envoyé par sevyc64

Mais dans la réalité du code, nous allons tous vers des variables aux noms relativement courts.

Euh plus maintenant avec autocomplete j'ai moins de mal à écrire des noms de variable assez long et quand je vois le projet où je suis où certains accronymes ont deux significations

omarcisses · 25/06/2012, 16h35

Citation:

Envoyé par sevyc64

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.

souviron34 · 26/06/2012, 10h35

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

Paul TOTH · 26/06/2012, 11h25

Citation:

Envoyé par souviron34

J'avoue ne pas très bien saisir l'intérêt de cette nouvelle discussion ...

c'est parce que PC c'est mieux que Mac

sevyc64 · 26/06/2012, 11h28

Citation:

Envoyé par souviron34

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 :

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.

ManusDei · 26/06/2012, 11h34

Citation:

Envoyé par souviron34

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 :

L'informatique, c'est pas le métier où on réinvente la roue régulièrement ?
A recoder ce qui a déjà été codé avant, et mieux, par d'autres personnes ?

Loceka · 26/06/2012, 11h35

Citation:

Envoyé par sevyc64

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.

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.

Bktero · 26/06/2012, 11h45

Citation:

Envoyé par Paul TOTH

c'est parce que PC c'est mieux que Mac

J'ai ri (mais vu le -1 accolé au message, quelqu'un d'autre n'a pas fait de même)

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 !)

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.

Je ne vois pas du tout là.......

BenoitM · 26/06/2012, 13h30

Citation:

Envoyé par sevyc64

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.

Peut-être mais quand on voit la pratique a premiere vu il faudra encore en parler souvent

deathness · 27/06/2012, 09h18

Citation:

Envoyé par ManusDei

L'informatique, c'est pas le métier où on réinvente la roue régulièrement ?
A recoder ce qui a déjà été codé avant, et mieux, par d'autres personnes ?

A malheureux mais si on ne refaisait pas toujours tout en convainquant les clients que c'est nécessaire, on ne servira plus à rien! 75% de dev au chomage !

BROWNY · 27/06/2012, 09h24

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

EtherOS · 04/09/2012, 00h43

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

26/06/2012, 10h35	#48
souviron34 Expert Confirmé Sénior Inscription : janvier 2007 Messages : 9 651 Détails du profil Informations personnelles : Âge : 55 Informations forums : Inscription : janvier 2007 Messages : 9 651 Points : 12 082 Points : 12 082	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 __________________ "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle". *Consultant indépendant. Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie. C, Fortran, XWindow/Motif, Java Je ne réponds pas aux MP techniques*
	20

27/06/2012, 09h24	#56
BROWNY Membre chevronné Toto Browny Développeur informatique Inscription : mars 2008 Messages : 521 Détails du profil Informations personnelles : Nom : Toto Browny Âge : 32 Localisation : France, Haute Vienne (Limousin) Informations professionnelles : Activité : Développeur informatique Secteur : Distribution Informations forums : Inscription : mars 2008 Messages : 521 Points : 615 Points : 615	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 __________________ Créateur de bugs professionnel Ma philosophie en 4 temps: -Ce n'est qu'en essayant continuellement que l'on finit par réussir. -Plus ça rate, plus on a de chances que ça marche. -Ne jamais révéler tout son savoir -...
	00

04/09/2012, 00h43	#57
EtherOS Membre habitué Lionel Tidjon Etudiant Polytechnicien Inscription : juillet 2012 Messages : 53 Détails du profil Informations personnelles : Nom : Lionel Tidjon Localisation : Cameroun Informations professionnelles : Activité : Etudiant Polytechnicien Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : juillet 2012 Messages : 53 Points : 115 Points : 115	Ma Proposition 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*
	11

25/06/2012, 14h29	#44
ManusDei Membre Expert esclave du Grand Capital Inscription : février 2010 Messages : 1 089 Détails du profil Informations personnelles : Sexe : Âge : 28 Localisation : France Informations professionnelles : Activité : esclave du Grand Capital Informations forums : Inscription : février 2010 Messages : 1 089 Points : 2 410 Points : 2 410	Tu veux qu'on s'use les doigts toi malheureux
	20

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email