Discussion :

[ptah35]

remarque pertinente à laquelle je vais répondre : pour la très simple raison qu'avant il y a 20ans UML ,les méthodologies n'existaient pas ou presque , que les compilateurs et les outils de développement ne permettaient pas de faire de la programmation objet..c'est tout simple
Donc il y a 20ans on ne pouvait pas construire un projet informatique de manière modulaire et structurée comme on peut le faire maintenant

L'informatique est jeune, je veux bien l'admettre, mais j'ai du mal à croire que vous puissiez affirmer qu'il y a 20 ans, on programmait sans méthodologie, en fait, je me sens presque insulté!

Vous n'avez visiblement pas la moindre notion d'histoire de l'informatique -- que vous semblez confondre avec celle de la micro-informatique. Si l'on compte large, la programmation orientée-objet a plus de 50 ans avec Simula et Smalltalk en a au moins 40 ! S'agissant de modélisation, croyez-vous vraiment que l'on a attendu UML pour en faire ? Est-ce que vous croyez vraiment qu'UML est sorti du néant ? Sachez que la première édition de OOPSLA a eu lieu en 1986 (il y a déjà 27 ans) et que l'idée d'utiliser la notion de design pattern en génie logiciel date de l'année suivante !

On ne peut pas tout savoir, mais il faut en être conscient et faire preuve de modestie. Si la micro-informatique n'a pas encore 40 ans, l'informatique en a pas loin de 70 et plus encore si l'on compte la mécanographie à laquelle ont doit une bonne partie de notre vocabulaire (fichier par exemple).

[Malick]

Bonjour,
à mon avis, il est toujours bon de commenter les codes; ceci aidera les tiers personnes (surtout les débutants) à comprendre sans trop de difficultés.

[koala01]

Bonjour,
à mon avis, il est toujours bon de commenter les codes; ceci aidera les tiers personnes (surtout les débutants) à comprendre sans trop de difficultés.

Si ton code est à visée pédagogique (comprends : qu'il est écrit pour justement permettre à un débutant d'apprendre le langage ou la programmation en générale), ton argument tient la route.

Mais, dans un code de production, on est malgré tout en droit d'attendre de la part d'un développeur qu'il connaisse "un minimum" le langage avec lequel il travaille ou, à défaut, qu'il soit "un minimum en mesure" de faire le parallèle avec un langage qu'il connaît.

A partir de ce point, on peut se demander ce qu'un commentaire apporte par rapport au code, et le problème devient la pérennité du commentaire par rapport au code.

Si le commentaire permet réellement de comprendre une idée qui n'apparaît pas clairement au travers de ton code, c'est sans doute que le code lui-même devrait être revu, en choisissant des noms de variables, de types et de fonction plus explicites, ce qui nous fait, de facto, tomber dans le cas suivant.

Si le commentaire n'apporte rien de plus par rapport au code, il est purement et simplement inutile et, à ce titre, il devient aussi dangereux que du code inutile car source d'erreur, surtout s'il n'est pas correctement mis à jour en même temps que le code.

Et donc, si tu veux que ton commentaire soit pérenne, il faut qu'il fournisse au lecteur une information qui sera indépendante du code en lui-même. Il faut donc qu'il explique la fonctionnalité -- en ajoutant, pourquoi pas, une aide à la décision qui permette de choisir entre deux fonctionnalités équivalentes -- plus que le moyen mis en oeuvre pour y arriver, et cela ne se fait pas dans le code lui-même: cela se fera dans un cartouche.

Je n'ai rien contre un commentaire qui prendrait la forme de

Code c++ :

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
17
18
19
20
/* Trie la collection selon le comparateur fourni.
 *
 * Utilise le comparateur pour effectuer un tri par insertion.
 * paramètre template Collection : le type de collection à trier.
 * paramètre template Comparateur : Le type de comparateur à
 *                                     utiliser lors du tri.
* parametre (in) collection : La collection d'objets à trier.
* précondition : Les éléments de la collection doivent être
*               copiables et comparables à l'aide du
*               comparateur indiqué.
* renvoie : Une nouvelle collection contenant les objets triés
*           dans l'ordre prescrit par le comparateur.
* nota    : La collection originale n'est pas modifiée lors du tri.
* voir aussi : Peut-être préférerez-vous la fonction triQuickSort.
*/
template <typename Collection, typename Comparateur>
Collection triParInsertion(Collection const & col,
Comparateur comparateur){
 
}

Mais je ne vois pas la moindre raison de placer un commentaire entre l'accolade ouvrante et l'accolade fermante de la fonction

[sekaijin]

...

Je n'ai rien contre un commentaire qui prendrait la forme de

Code c++ :

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
17
18
19
20
/* Trie la collection selon le comparateur fourni.
 *
 * Utilise le comparateur pour effectuer un tri par insertion.
 * paramètre template Collection : le type de collection à trier.
 * paramètre template Comparateur : Le type de comparateur à
 *                                     utiliser lors du tri.
* parametre (in) collection : La collection d'objets à trier.
* précondition : Les éléments de la collection doivent être
*               copiables et comparables à l'aide du
*               comparateur indiqué.
* renvoie : Une nouvelle collection contenant les objets triés
*           dans l'ordre prescrit par le comparateur.
* nota    : La collection originale n'est pas modifiée lors du tri.
* voir aussi : Peut-être préférerez-vous la fonction triQuickSort.
*/
template <typename Collection, typename Comparateur>
Collection triParInsertion(Collection const & col,
Comparateur comparateur){
 
}

Ceci c'est de la documentation de l'API pas un commentaire il devrait commencer par /** et non /*.

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/** 
 * Trie la collection selon le comparateur fourni.
 * Utilise le comparateur pour effectuer un tri par insertion.
 * nota    : La collection originale n'est pas modifiée lors du tri.
 * @param Collection col : La collection d'objets à trier.
 * @param Comparateur comparateur : comparateur à utiliser lors du tri.
 * @return : Une nouvelle collection contenant les objets triés dans l'ordre prescrit par le comparateur.
 * @see Peut-être préférerez-vous la fonction triQuickSort.
 */
template <typename Collection, typename Comparateur>
Collection triParInsertion(Collection const & col,
Comparateur comparateur){
 
}

A+JYT

[koala01]

Ceci c'est de la documentation de l'API pas un commentaire il devrait commencer par /** et non [CODEinline]/*[/CODEinline

Pas forcément : /** est surtout intéressant parce que c'est un lexème utilisé par certains outils génération de documentation automatique, comme doxygen, mais autrement, ce n'est qu'une question de convention et cela dépend fortement d'une équipe à une autre

Ceci dit, tu as au moins raison sur un point : la très grosse majorité des commentaires réellement utiles (car on ne peut exclure tout à fait la possibilité qu'il y ait d'autre commentaires réellement utiles ) sont destinés à commenter des éléments de l'api et non le code lui-même

[Neckara]

Et moi qui croyait qu'on en avait fini avec ce débat

Un cas dans lequel il peut être intéressant de mettre des commentaires à l'intérieur des fonctions serait la mise en valeur d'une ligne spécifique.

Par exemple, si on sait qu'il y a une erreur à une ligne précise sans qu'on sache comment la corriger, on peut la signaler dans la documentation (@todo ou @warning) mais aussi à l'intérieur de la fonction pour la retrouver plus rapidement.

Mais je suis presque sûr qu'on a déjà dit cela dans les pages précédentes, ne commencerait-on pas à tourner en rond?