Discussion :

[gl]

milie les pré-condition dans les langages de programmation ce sont les bibliothèques avec des assertions non ? Tu veux dire qu'elles ne sont pas très développées (existantes) pour les mathématiques ?

Le problème n'est pas si simple que ça et se situe en fait, non dans les bibliothèques mais dans le langage lui-même.

Dans les faits, de nombreux langage pourtant très répandus n'intègre pas de mécanisme permettant de gérer les pré-conditions qui soit à la fois efficace, simple et qui documente ces pré-conditions.
Prenons par exemple le cas du C ou du C++ (mais de ce que j'en sais, ce n'est pas très différent en Java et probablement pas en C#):

• Les assert ne remplissent pas ce rôle : inactif en mode release, sortie violente du programme, etc.
• Les static_assert de Boost (et d'autres solutions similaires) bien que très pratique ne le remplisse pas non plus : résolu lors de la compilation donc il ne peuvent pas servir à vérifier une valeur connue uniquement au run-time.
• Le test explicite dans le code avec retour du code d'erreur adéquate : la méthode peut être efficace si le code est bien écrit, toutefois elle ne remplit pas le rôle documentaire (pas de mise en évidence, noyé dans le code qui n'est pas forcément disponible) et nécessite d'écrire pas mal de code pour gérer ces cas ce qui "pollue" le code fonctionnel (même s'il est possible de mettre ses vérifications dans une couche intermédiaire) et augmente le risque d'erreur (plus de code ==> plus de risque d'erreur).
• Les différentes sur-couches maison plus ou moins bien pensées qui encapsulent les tests et fournissent des fonctionnalités de vérification ne permettent pas une expressivité des conditions toujours suffisante.

Alors effectivement une fois que la bibliothèque est développée, validée, documentée et éprouvée, on peut se dire que les méthodes existantes sont suffisantes. Mais parvenir à ce résultat nécessite un travail important qui pourrait être amplement facilité si le langage fournissait nativement ce mécanisme.

[hegros]

Si vous considerez ces informations pas comme des "vrais" commentaires, alors j'ai parlé dans le vent

Ce sont des vrais faux commentaires

précondition et postcondition c'est plutôt écrit avec un langage formel du coup c'est vraiment exploitable en plus de différentes manières soit plus intéressant

En plus ce n'est pas le type de commentaire que j'appelle inutile même si je pense que cela peut être autant explicite avec le code. L'exemple de Chatanga est beaucoup plus parlant, en tout cas à moi, que ton exemple avec commentaire et pourtant il n'en nécessite pas probablement parce que tu l'écris de ton point de vue 'mathématicien' alors que je suis 'développeur'

En revanche, si le langage est prévu pour, en général :
- les préconditions sont affichés dans la documentation générée
- les préconditions sont liées à la signature de la fonction
Dans ce cas, pas besoin de documenter dans le code ces points.

Pour le 2ième point, en JAVA dans la signature on peut expliciter une exception cela pourrait être une exception de type ExcepPreCond1 ou ExceptRegleMath1. Il me semble bien que la javadoc prends en compte les @exception pour la documentation.

[souviron34]

Bon, je ne vais pas autant développer que de l'autre côté, mais certains trucs dits ici me font réagir ...

Ensuite c'est une question de process l'automatisation de la documentation peut se faire de la manière qu'on souhaite soit en rétro soit en merge soit par une chaîne de compilation comme l'exposé dans la discution gl.

Je ne sais pas quelle fixation tu fais sur l'auto-documentation, mais cela ne contient (et ne convient) qu'à une infîme partie de la documentation d'un logiciel...

La justification qui me fait rire c'est commentez pour expliquer une partie obscure J'appelle cela plus une prouesse qu'un commentaire

On en reparlera quand tu seras tombé sur un algo hyper-spécialisé , avec super-optimisation....

Mon contexte = multi-projet/multi-équipe pour l'industrie médical et on ne livre pas au client de classe .java des modules oui mais executable donc c'est plus après pour faire de l'intégration que du développement et les évolutions oui mais cela prends du temps dans ce secteur (nouveau en même temps avant j'étais dans une usine à gaz )

A plus forte raison : dans le domaine médical, pratiquement 100% des cas la maintenance est faite par l' (ou les) équipe(s) de maintenance, totalement détachée(s) (souvent dans un autre pays, pour raisons commerciales) de l'équipe de développement, elle même souvent détachée de l'équipe de production, avec ses(leurs) propres outils / contextes / conventions / documentations...

On dirait pas à t'écouter le commentaire que tu as écris il y a 10 ans sera interpreté de la même façon par une autre personne dans 10 ans. Dans ce cas bravo j'aimerais bien le lire ce commentaire.

J'espère bien qu'un commentaire écrit il y a 10 ans sera lu dans 10 ans avec la même compréhension...

C'est à ça que ça sert, un commentaire !!!!!!

Nous sommes alors d'accord pour dire que les commentaires ont peu d'effet positif sur la maintenance quand on sait que cela représente 70% du temps d'un cycle de vie logiciel et des coûts on pouvait en espérer autrement pour toute la machinerie qui est mis en route derrière pour générer la documentation et le suivi du versionning.

Par rapport à ce qu'explique Garulfo sur le problème de coût de maintenance probablement que les défauts de commentaires ne devraient pas atteindre une part immense en fait je n'en sais rien il doit y avoir des graphiques qui l'expriment.

Non seulement tu interpètes mal ce qu'on dit, mais en plus tu le cites comme appui de tes arguments, alors que cela va dans le sens contraire...

PUISQUE la maintenance fait 70% du temps de ve d'un logiciel, les commentaires sont essentiels....

Pour moi, un commentaire ne doit pas décrire ce que fait un élément de code sauf si cet élément de code est mal écrit (et donc difficile à comprendre) et qu'il n'est pas possible de le réécrire. Dans ce cas là, je parle de commentaires factuels. Par exemple, quand j'ai à reprendre un code existant, j'ai l'habitude d'écrire des tas de commentaires factuels dans le code qui disparaitront au fur et à mesure du refactoring si ce dernier est envisageable. Alternativement, quand j'écris directement du code, je factorise naturellement chaque commentaire factuel en une méthode et ses paramétres en structures de données complexes (du moins quand je suis bien révéillé).

Idéalement et c'est pour moi un motif de satisfaction qu'en j'y arrive, mon code s'articule en deux étapes : construction d'une grammaire (faite de méthodes et de classes) adaptée à mon problème à l'aide des briques polyvalentes du langage et expression du problème et de sa solution dans cette grammaire. Le résultat est naturellement lisible sans nécessité d'être paraphrasé.

Donc, les commentaires factuels perdent naturellement leur utilité quand un code est bien écrit. Il existe néanmoins des commentaires pour tout le reste : souligner au lecteur certaines parties du code significatives (une section critique, une exécution couteuse en temps, une non-portabilité à envisager), détailler le contexte (à quoi servira en pratique telle donnée construite à tel endroit, la raison d'une approche plutôt qu'une autre tout aussi valide à tel autre endroit) et ainsi de suite. L'élément commun à tous ces commentaires est à mon sens l'intention pédagogique (et c'est pour ça qu'ils sont difficules à écrire pour celui qui crée un code et qui le connait intimement). Alternativement, dans le cas où seule l'interface d'une méthode est disponible, la vertue pédagogique d'un commentaire devient indispensable pour un lecteur qui n'a pas accès à son implémentation (un peu comme s'il ne savait pas en lire le langage).

100% d'accord..

On pourrait comparer un code sans commentaires à un livre de mathématique constitué uniquement de formules.
..

Oui, avec les nuances apportées par gl.

milie les pré-condition dans les langages de programmation ce sont les bibliothèques avec des assertions non ? Tu veux dire qu'elles ne sont pas très développées (existantes) pour les mathématiques ?

Encore une fois, quelle vision restrictive !!!!!!

Les asserts ne sont qu'une minuscule partie des préconditions...

Les pré-conditions fonctionelles, par exemple, ne sont pas soumises aux asserts...

précondition et postcondition c'est plutôt écrit avec un langage formel du coup c'est vraiment exploitable en plus de différentes manières soit plus intéressant

Encore une fois, tu as visiblement des oeillères sur la manière de fonctionner..
Dans l'enchaînement d'une suite d'écrans, ou dans l'inaccessibilité (ou sa soudaine accessibilité) d'un bouton dans une fenêtre, rien de tout ceci n'est exprimé sous forme d'un langage formel dans un logiciel....

Pour le 2ième point, en JAVA dans la signature on peut expliciter une exception cela pourrait être une exception de type ExcepPreCond1 ou ExceptRegleMath1. Il me semble bien que la javadoc prends en compte les @exception pour la documentation.

Et si il y a 10 exceptions, et que chacune contient 10 cas ?



En résumé, et sans vouloir être méchant, tu affirmes tout un tas de trucs que tu prétends être "professionnels" et d'"avis expert", alors que visiblement tu manques cruellement d'exéprience, et de réflexion sur la réalité des choses, et de plus tu sembles tellement convaincu qu'il semble extrêmement difficile à des gens ayant réellement de l'expérience ou de la réflexion de te faire entendre quoi que ce soit....


Je suis désolé, mais ce n'est pas vraiment une discussion, ni dans ce thread ni dans l'autre.. Tu as une vision bornée à tes outils actuels et ta manière actuelle de procéder, et, come le dit Garulfo, cela semble êtrre beaucoup plus proche du "je travaille tout seul sur un petit projet" qu'autre chose..

Et, comme d'après ce que tu dis tu travailles avec d'autres, eh bien je plains sincèrement vos suivants, si tout le monde dans ta boîte travaille comme toi...

[Leonhart]

Bonjour,

Je ne sais même pas comment cette question a pu etre poser !

Bien sur qu'il faut des commentaires, et il en faut beaucoup. Je pense que la règle (si elle en est une) des 1/3 est assez représentative car il est nécessaire de commenter les ensembles semantiques de codes - et elles font souvent plusieurs lignes.

Les commentaires sont utiles pour la maintenance mais pas seulement. Car quand on doit re-sortir un driver pour bus de terrain sur un Microprocesseur exotique le totu avec un OS temps réels, il faut s'accrocher à ses chaussettes.

Néanmoins, ils ne sont pas nécessaires. Il est primordiale de creer une documentation compléte sur chaques développement car il pourra nécéssité une réutilisation ou une ré-écriture, par soi-même ou non. Et a ce moment là, un indice sur le pourquoi de cette instruction ou du contenu d'un registre est fortement appréciable.

Enfin après, c'est vous qui voyez ...

[hegros]

Je ne sais pas quelle fixation tu fais sur l'auto-documentation, mais cela ne contient (et ne convient) qu'à une infîme partie de la documentation d'un logiciel...

Aujourd'hui c'est plus utilisé pour la documentation technique à la javadoc c'est peut-être infime mais cela marche bien.

J'espère bien qu'un commentaire écrit il y a 10 ans sera lu dans 10 ans avec la même compréhension...

Si tu en as un en exemple ne te gêne surtout pas !

PUISQUE la maintenance fait 70% du temps de ve d'un logiciel, les commentaires sont essentiels....

C'est dingue on écrit des commentaires depuis la nuit des temps en informatique et pourtant les couts en maintenance ne font qu'augmenter c'est étrange non ?

Et si il y a 10 exceptions, et que chacune contient 10 cas ?

Il est possible de généraliser les exceptions. ExceptReglMath1 ExceptReglMath2 peuvent très bien hériter de ExceptReglMath etc...

En résumé, et sans vouloir être méchant, tu affirmes tout un tas de trucs que tu prétends être "professionnels" et d'"avis expert", alors que visiblement tu manques cruellement d'exéprience, et de réflexion sur la réalité des choses, et de plus tu sembles tellement convaincu qu'il semble extrêmement difficile à des gens ayant réellement de l'expérience ou de la réflexion de te faire entendre quoi que ce soit....

Une personne expérimentée avec 20 ans ou 30 ans peut aussi faire des erreurs ce n'est pas parce que tu as cet âge dans le métiers que tu as raison sur tout.

Je suis désolé, mais ce n'est pas vraiment une discussion, ni dans ce thread ni dans l'autre.. Tu as une vision bornée à tes outils actuels et ta manière actuelle de procéder, et, come le dit Garulfo, cela semble êtrre beaucoup plus proche du "je travaille tout seul sur un petit projet" qu'autre chose..

J'ai toujours travaillé en équipe(là nous sommes plus d'une dizaine) puis dans les intervenants (toi et garulfo par exemple) avez aussi une vision très dogmatique sur la question. Pourtant personne n'enseigne à commentez comme quoi cela ne doit pas être le primordial.

Et, comme d'après ce que tu dis tu travailles avec d'autres, eh bien je plains sincèrement vos suivants, si tout le monde dans ta boîte travaille comme toi...

Dans ma dernière boîte on a ouvert 4-5 centres de production de gaz en 1-2 années et j'étais le concepteur-développeur principal de ce projet et cela marche toujours aujourd'hui sans mon intervention puisque je ne fais plus parti de cette entreprise (bien qu'ayant gardé mes contacts la bas)

[souviron34]

Une personne expérimentée avec 20 ans ou 30 ans peut aussi faire des erreurs ce n'est pas parce que tu as cet âge dans le métiers que tu as raison sur tout.
..
J'ai toujours travaillé en équipe(là nous sommes plus d'une dizaine) puis dans les intervenants (toi et garulfo par exemple) avez aussi une vision très dogmatique sur la question. Pourtant personne n'enseigne à commentez comme quoi cela ne doit pas être le primordial.

c'est bizarre, mais que ce soit dans l'autre thread ou dans celui-ci, tu es strictement le seul à défendre ta position.. Chatanga ayant répondu oui pour ne pas faire un sondage stalinien...

Alors je ne crois pas que ce soit lié à l'âge..

Je n'ai jamais dit que j'avais raison sur tout, mais quand tu es sur un forum de professionnels, et que tous ces professionnels sauf toi sont d'un avis contraire au tien, ben, ya pt'êt une raison, non ??????






Quant à l'âge, sans avoir la Vérité Universelle, permet cependant que nous soyons plusieurs sur ce site à avoir très nettement plus d'expérience que toi..
Et que ça ne fait pas de nous des dinosaures d'un autre temps...

C'est tout..

[Garulfo]

Aujourd'hui c'est plus utilisé pour la documentation technique à la javadoc c'est peut-être infime mais cela marche bien.[...]

La documentation à la javadoc n'est pas du code auto-documenté. C'est de la documentation classique en bon et dû forme. Si tu appelles ça du code auto-documenté alors nous avons là la source de tout ce malentendu !
Le code auto-documenté c'est que le code lui-même se lit comme une documentation.

Comme tu le dis la documentation technique générée à partir de la documentation du code est une technique qui fonctionne très bien et qui est très répandue. C'est nécessaire encore une fois d'avoir ce genre de documentation. Le code auto-documenté ne suffit pas ! J'aimerais bien que tu essayes de trouver une référence sérieuse qui indique que le code auto-documenté suffit. Par référence sérieuse, ça sous-entend pas un blog ou la remarque d'un programmeur sur un forum… on est d'accord ?

Je ne remets pas en cause tes capacités en tant que professionnel dans ce que tu fais. Mais je ne crois pas que tu ais une réelle vision de ce qu'est un projet lorsque je te lis. Peut-être ai-je tort… et peut-être finalement est-ce un simple malentendu sur quelque terme… mais il me semble que tu connais surtout ta partie technique et que tu ne comprends pas les tenants et aboutissants d'autres parties du développement logiciel que tu ne côtoies pas.

Je suis un peu étonné de ton entêtement à dire, peu ou prou, coute que coute que les commentaires sont inutiles dans du code. Bon tout le monde peut se tromper c'est vrai. Ça s'est vu des cas où même les « spécialistes » étaient à côté de la plaque. Mais personnellement dans un cas comme ça, je deviens prudent; je dis « je vais y réfléchir »; je prends un pause pour m'assurer qu'au moins j'ai un argumentaire béton. Là, tu passes plus pour une tête de mule qu'autre chose Ce qui n'est pas plus grave que ça au final remarques bien ! ^_^

[hegros]

tu ne comprends pas Souviron et d'autres surement car c'est pratique.

j'ouvre mon éditeur favori du moment Eclipse voir les projets qui traînent en java...mouais des lignes et des lignes de code mais aucun commentaire..prenons un cas d'un article que je devais rédiger depuis un bail...

En même temps c'est plus une partie graphique basique mais j'ai pleins de petits fichiers (pas des mille et des cents)comme cela en java...

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
package ui;

import java.awt.Dimension;
import java.util.ArrayList;

public class VCentraleCo2 extends VFrame {

	private ArrayList listFrames = new ArrayList();
	private String description ;
	private String name;		
		
	
	public VCentraleCo2(String name, String description)
	{		
		this.name=name;
		this.description =description;
	}
	
	public void add(VFrame vframe)
	{
		System.out.println("add dans " +name);
		listFrames.add(vframe);
	}
	
	public void remove(VFrame vframe)
	{
		listFrames.remove(vframe);
	}
	
	public VFrame getChild(int i)
	{
		return (VFrame)listFrames.get(i);
	}
	
	public String getDescription()
	{
		return description;
	}
	
	public String getName()
	{
		return name;
	}
	
	public void createControls()
	{
		System.out.println("creation des controles de " +name);
	}
	
	public void createView()
	{
		System.out.println("creation de la vue " +
								getName() +"-"+getDescription());
		setTitle(getName());			
	}
	
	public void print()
	{
		setVisible(true);
		int nbFrame = listFrames.size();
		
		System.out.println("nombre de frame dans " + name + " : "+ nbFrame );											
	}	
}

Si c'est tip-top comme cela et qu'on ne veut pas s'encombrer avec la génération automatique de documentation c'est bien aussi non ...

[hegros]

La documentation à la javadoc n'est pas du code auto-documenté. C'est de la documentation classique en bon et dû forme. Si tu appelles ça du code auto-documenté alors nous avons là la source de tout ce malentendu !
Le code auto-documenté c'est que le code lui-même se lit comme une documentation.

Comme tu le dis la documentation technique générée à partir de la documentation du code est une technique qui fonctionne très bien et qui est très répandue. C'est nécessaire encore une fois d'avoir ce genre de documentation. Le code auto-documenté ne suffit pas ! J'aimerais bien que tu essayes de trouver une référence sérieuse qui indique que le code auto-documenté suffit. Par référence sérieuse, ça sous-entend pas un blog ou la remarque d'un programmeur sur un forum… on est d'accord ?

Heureusement que j'ai précisé 'infime'

Je suis un peu étonné de ton entêtement à dire, peu ou prou, coute que coute que les commentaires sont inutiles dans du code. Bon tout le monde peut se tromper c'est vrai. Ça s'est vu des cas où même les « spécialistes » étaient à côté de la plaque. Mais personnellement dans un cas comme ça, je deviens prudent; je dis « je vais y réfléchir »; je prends un pause pour m'assurer qu'au moins j'ai un argumentaire béton. Là, tu passes plus pour une tête de mule qu'autre chose Ce qui n'est pas plus grave que ça au final remarques bien ! ^_^

Soyons clair. Ce sondage est stupide et idiot il n'y a qu'un imbécile qui suivra la règle 'ne commentez jamais votre code' cela est venu naturellement avec le sujet code propre pour développer le sujet c'est tout.

Je suis plus un partisan de

commentez toujours votre code lorsqu'il y a un besoin mais n'en rajoutez pas plus

[Tommy31]

- les outils du type javadoc n'extrait pas les assertions et donc la génération de la documentation ne donne aucune indication là dessus (à moins de passer par des tags, mais cela ne marchera que pour des préconditions informatives )

Les annotations sont un bon moyen d'exprimer des préconditions en java (>1.4), et ceci au niveau de la signature. Bien entendu celles-ci sont rendues visibles à la génération de la documentation et elles sont porteuses d'un sens bien précis (par typage).

Code :

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

1
2
3
4
public double sommeGeometrique(@Nonnegative int n, @Notequal(1) double q) { 
  retourner (1-q^(n+1))/(1-q);
}

[souviron34]

tu ne comprends pas Souviron et d'autres surement car c'est pratique.

Non, je ne comprend réellement pas..

Si c'est tip-top comme cela et qu'on ne veut pas s'encombrer avec la génération automatique de documentation c'est bien aussi non ...

je vois un code comme celui que tu montres, j'ai 2 attitudes :

• c'est moi qui reprend le code, je le documente.
• Je suis le chef de projet, je te donne un avertissement. Tu insistes, je te vire ou alors je te mets un coach..

Pour moi, non seulement c'est pas tip-top, c'est le contraire d'un code propre.. C'est poubelle direct...

Déjà même pas de commentaires d'entête...

Comment je sais ce que c'est moi, "VCentraleCo2" ??? un widget ? un objet métier ? une sous-classe ?


Et comment, à part traverser tout le fichier, je sais qu'est-ce que cette classe possède comme méthodes publiques ou privées ??

Aucune indication de ce à quoi ça correspond, ni dans l'interface, ni dans la fonctionalité..


Absolument merdique...

[Tommy31]

Et comment, à part traverser tout le fichier, je sais qu'est-ce que cette classe possède comme méthodes publiques ou privées ??

Un bon ide est une aide précieuse, pas seulement pour les fonctions de découverte des facettes d'une classe, mais aussi pour la navigation parmi les liens tissés dans le code (quels sont les appelés/appelants, quels sont les héritiers/ancêtres).

Absolument merdique...

d'accord, mais n'est-ce pas mieux que ceci (que l'on voit d'expérience trop souvent) :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
package ui;

// Imports de la classe
import java.awt.Dimension;
import java.util.ArrayList;

/**
 * Classe modélisant une centrale de co2.
 *
 * @author Hegros
 */
public class VCentraleCo2 extends VFrame {

        /** Contient la liste des cadres */
	private ArrayList listFrames = new ArrayList();
       /** description de la centrale */
	private String description ;
      /** nom de la centrale */
	private String name;		
		

/**
 * Constructeur.
 * param name le nom de la centrale
 * param description la description de la centrale
 */	
	public VCentraleCo2(String name, String description)
	{		
               // affecte les propriétés
		this.name=name;
		this.description =description;
	}
	
       /**
        * Ajoute un autre cadre .
        * @param vframe le cadre à ajouter.
        */
	public void add(VFrame vframe)
	{
		System.out.println("add dans " +name);
		listFrames.add(vframe);
	}
	
     
      /**
        * Supprime un cadre .
        * @param vframe le cadre à supprimer.        */
	public void remove(VFrame vframe)
	{
		listFrames.remove(vframe);
	}
	
       /** 
         * Retourne un cadre selon son index.
         * @param i l'index du cadre à retourner
         * @return le cadre selon l'index fourni
          */
	public VFrame getChild(int i)
	{
		return (VFrame)listFrames.get(i);
	}
	
       /**
        * @return la description de la centrale
        */
	public String getDescription()
	{
		return description;
	}
	
        /**
          * @return le nom de la centrale
          */
	public String getName()
	{
		return name;
	}
	
        /**
         * Crée les controles.
         */
	public void createControls()
	{
		System.out.println("creation des controles de " +name);
	}
	
        /**
          * Créé la vue.
          */
	public void createView()
	{
		System.out.println("creation de la vue " +
								getName() +"-"+getDescription());
		setTitle(getName());			
	}
	
       /**
        * Affiche le nombre de cadres.
        */
	public void print()
	{
		setVisible(true);
		int nbFrame = listFrames.size();
		
		System.out.println("nombre de frame dans " + name + " : "+ nbFrame );											
	}	
} // fin de la classe VCentraleCo2

C'est verbeux, redondant et finalement sans apport révélateur.

[souviron34]

Un bon ide est une aide précieuse, pas seulement pour les fonctions de découverte des facettes d'une classe, mais aussi pour la navigation parmi les liens tissés dans le code (quels sont les appelés/appelants, quels sont les héritiers/ancêtres).

Mais peut-être que tu n'auras pas à disposition un bon ide quand tu regarderas ce code ??

On t'enverras peut-être un mail quand tu es vacances, que tu ne feras que consulter au cybercafé du coin, et auquel on te demandera de répondre instantanément...

d'accord, mais n'est-ce pas mieux que ceci (que l'on voit d'expérience trop souvent) :
..
C'est verbeux, redondant et finalement sans apport révélateur.

Non, je trouve que c'est pire..

Admettons que je souhaite changer de langage graphique, et que ce langage ne possède pas les mêmes facultés que le précédent.

Au moins, avec les commentaires, je peux remplacer au coup par coup, et garder une certaine structure..

M'enfin, il est bien évident que dans le cas présenté, je me fais un peu l'avocat du diable. Cependant, pour moi je trouve pire de ne rien avoir...

[white_tentacle]

C'est verbeux, redondant et finalement sans apport révélateur.

En fait, si, c'est quand même utile, même si c'est loin d'être top. Ne serait-ce que parce que ça n'est pas dans la même langue que les noms des fonctions .

En plus :

Code :

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

1
2
3
4
/**
  * Affiche le nombre de cadres
 **/
public void print()

Je t'avoue que sans le commentaire, jamais je n'aurais pensé que ça affichait le nombre de cadres. Après, on rétorquera que c'est parce que la fonction est mal nommée, soit, mais le commentaire ici m'apporte une précision utile.

Après, c'est clairement insuffisant :

Code :

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

1
2
3
4
/**
        * Supprime un cadre .
        * @param vframe le cadre à supprimer.        */
        public void remove(VFrame vframe)

On ne sait même pas ce qu'il se passe si vframe n'est pas dans la liste actuelle...

[Tommy31]

Mais peut-être que tu n'auras pas à disposition un bon ide quand tu regarderas ce code ??

On t'enverras peut-être un mail quand tu es vacances, que tu ne feras que consulter au cybercafé du coin, et auquel on te demandera de répondre instantanément...

Tu prêches un convaincu ; celà dit, je dois admettre que nombre de fois les commentaires se sont révélés très insuffisants. En pareil cas, je me sens bien démuni sans un bon outil d'investigation...

Non, je trouve que c'est pire..

Sans commentaire, je maudis le mec qui a pondu ça pour 1 génération. Avec commentaires, je pense immédiatement que c'est un brave type, que le mec est un disciple de souviron, qu'il a pensé à son prochain... jusqu'à ce que je me rende compte que les commentaires sont vaporeux et qu'ils ne servent à rien. Et m'empresser de le maudire pour 5 générations avant de faire une dépression.

[hegros]

Après, c'est clairement insuffisant :

Code :

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

1
2
3
4
/**
        * Supprime un cadre .
        * @param vframe le cadre à supprimer.        */
        public void remove(VFrame vframe)

On ne sait même pas ce qu'il se passe si vframe n'est pas dans la liste actuelle...

C'est normal le code n'est pas fini je n'ai pas tout implémenté sinon j'aurais déjà publié l'article... c'est un départ en plus des petits fichiers .java j'en ai pleins des comme cela c'est un choix de découpage

Ensuite vous pouvez essayer de trouver un commentaire pertinent pour ce genre de méthode puisqu'à priori vous êtes connaisseur moi j'en ai pas trouvé !

[Garulfo]

[...]
commentez toujours votre code lorsqu'il y a un besoin mais n'en rajoutez pas plus

Ça je suppose que nous sommes finalement tous d'accord là-dessus ^_^

[Garulfo]

C'est normal le code n'est pas fini[...]
Ensuite vous pouvez essayer de trouver un commentaire pertinent pour ce genre de méthode puisqu'à priori vous êtes connaisseur moi j'en ai pas trouvé !

Ton commentaire doit exprimer ce que ta conception prévoit. As-tu fait une conception avant de coder ? Il semble que non. Tu sais que c'est une très mauvaise habitude ? En tout cas, ça n'a pas rapport donc avec le fait que ton code soit ou non fini. Tant que tu penses que le commentaire s'écrit après ton code, il est normal que tu penses qu'il n'en faut presque pas. Mais c'est là que ce situe ton erreur première je crois.

[hegros]

Ton commentaire doit exprimer ce que ta conception prévoit. As-tu fait une conception avant de coder ? Il semble que non. Tu sais que c'est une très mauvaise habitude ? En tout cas, ça n'a pas rapport donc avec le fait que ton code soit ou non fini. Tant que tu penses que le commentaire s'écrit après ton code, il est normal que tu penses qu'il n'en faut
presque pas. Mais c'est là que ce situe ton erreur première je crois.

Oui il y a une conception d'ailleurs tu remarqueras que c'est une implémentation du pattern composite pour une vue, autant faut-il le le reconnaître avec l'héritage et les méthodes add/remove et voir qu'on est dans le package ui (User Interface)

est-ce que ce commentaire 'implémentation du pattern composite pour la vue principale' est pertinent ?

peut-être que oui peut-être que non à vrai dire je n'ai pas l'habitude de commencer à coder avant d'avoir fais une conception et en principe aussi avec des tests...

[gl]

Je suis plus un partisan de

commentez toujours votre code lorsqu'il y a un besoin mais n'en rajoutez pas plus

Enfin !

Ca fait grosso-modo deux semaines que moi et quelques autres ne disons rien d'autre que ceci.