Discussion :

[omarcisses]

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]

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]

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]

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

[sevyc64]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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 !

[Pelote2012]

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]

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