maitretarot-devel-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maitretarot-devel-fr] Documentation


From: Philippe Brochard
Subject: Re: [Maitretarot-devel-fr] Documentation
Date: 05 Feb 2004 21:38:04 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

"Yves Mettier" <address@hidden> writes:

> >> OK, je ne savais pas que cl_game_server generait aussi la doc :)
> >>
> > Non, il ne genere pas la doc. Et je ne pense pas qu'il le fasse un jour :
> > c'est pas son boulot.
> 
> Je considere cela comme de la documentation du code.
> Pour ceux qui ne connaisent pas ma position sur ce sujet, je suis en grande 
> partie
> contre documenter son code, parce qu'un code doit etre ecrit de maniere 
> lisible.
> En ce qui concerne cardgame_server, on a un cas particulier. Le code contient 
> sa propre
> documentation et ne peux fonctioner sans ca. Ensuite, on pourrait extraire 
> cette doc
> avec un outil a part pour generer du docbook. Il etait aussi simple de le 
> coder a
> l'interieur de cardgame_server.
> 
> Donc en ce qui concerne cardgame_server, il y a d'une part la documentation 
> du code, et
> l'outil qui l'extrait pour generer du sgml. Pour cl_game_server, l'extraction 
> de la
> documentation, je suis tout a fait d'accord: c'est pas son boulot (idem pour
> cardgame_server, et c'est pour ca que j'avais pense a mettre ca dans 
> libmaitretarot et
> creer cardgame_server pour le serveur, et le generateur de doc a part). Pour 
> la
> documentation du code, c'est un choix a faire :)
> 
Oui, pour la doc du code, je suis du meme avis que toi : il vaut
mieux faire un code bien lisible (nom de fonction explicite) plutot
que des commentaires toutes les 2 lignes.

> >
> > Par contre la doc que j'avais mis sur le CVS, elle etait a jour (avec ce qui
> > est utilise dans cl_game_server). Et je pense qu'elle n'a plus de raison de
> > bouger : tout fonctionne impec avec les nouveaux client/ia.
> 
> J'avais eu l'impression que c'etait la doc de maitretarot. Dans ce cas: oops, 
> mea culpa.
> Je vais lire la doc pour recuperer un fichier supprime du CVS (tout l'interet 
> du CVS est
> la) et le restaurer. A moins que tu ne me devances ?
> 
bon, je regarde si tu l'as remis sur le CVS, sinon j'en ai une
copie en local => je le remet sur le CVS (tu me le vire pas
cette fois ci :))

> Par contre, je tiens a un point:
> - le module doc ne contient, en termes de protocole, que celui de 
> cardgame_server et de
> cl_game_server. Il ne doit pas contenir celui de maitretarot_server
> - le protocole de maitretarot_server, qui est abandonne, reste bien au chaud 
> la ou il
> est: dans le repertoire doc du module maitretarot.
> 
oui, le protocole obsolete doit rester sur le CVS mais pas etre trop
apparent pour qu'on ni fasse plus reference.

> > C'est pour ca que je me suis remis a libmt_client : le protocole est robuste
> > => on peut l'implementer.
> 
> \o/
> 
> ... et corriger cardgame_server pour qu'il l'applique.
> 
:)

> [...]
> 
> >> > Je prefere que celui qui veux coder un jeu de bellote developpe son 
> >> > propre serveur,
> >> > ecrive la doc du protocole qui lui a permis de jouer et en discute avec 
> >> > tout le
> >> > monde jusqu'a ce que le protocole soit accepte.
> >> > Ensuite libre a cardgame_server d'implemente le jeu de belotte ou a 
> >> > n'importe qui
> >> > d'autre qui veut juste coder un serveur de bellote.
> >> >
> >> > Et pour ca, il faut que la doc soit independante de toute implementation 
> >> > du serveur!
> >>
> >> On est sur la meme longueur d'onde. Faut juste le faire.
> >>
> > y a deja le protocole.sgml que j'avais mis dans documentation
> > (le chapitre 3 est a jour).
> 
> Si je ne me suis pas plante, je l'ai laisse dans guide.sgml.
> Par contre, je compte bien le supprimer de guide.sgml pour qu'il apparaisse 
> dans
> protocole.sgml.
> 
Bon, ben je met protocole.sgml avec seulement le chapitre 3
qui est a jour (si tu ne l'as pas deja fais).

> [...]
> 
> >> Dans cardgame_server, il y a des tableaux contenant ce qu'il faut pour 
> >> generer la doc.
> >> Il est tout a fait possible de modifier ces tableaux sans pour autant 
> >> modifier le
> >> fonctionnement du serveur. Tant que l'utilisation de ces tableaux n'est 
> >> pas faite,
> >> rien
> >> ne change. Et niveau doc, y'a juste a rajouter des lignes a ces tableaux.
> >>
> > ah, ok, je n'ai pas ete voir comment etait genere la doc.
> > Comment ca ce passe si on veux documente un nouveau jeu ?
> > Ce serai bien que ce soit facile d'acces dans un logiciel a
> > par.
> 
> On y avait reflechi, mais on n'avait pas pousse la reflexion tres loin.
> Je refais un nouveau thread avec ce sujet car j'ai pas mal d'experience sur 
> ce genre de
> choses: mail suivant.
> 
ok : vu


[...]


> >> Oui, tout a fait. Sauf pour le format du fichier que je prefere en format 
> >> docbook
> >> (sgml
> >> ou xml) car cela evite de tout refaire ensuite en docbook pour generer du 
> >> txt, html,
> >> ps
> >> ou pdf.
> >>
> > oui, je trouve aussi que docbook est pratique pour ca.
> 
> Un logiciel qui permet de generer automatiquement la doc... Si ca existait, 
> ca se
> saurait et ferait le bonheur des profs de programmation :)
> Mais on a au moins deux sortes d'aides a la generation de doc.
> 
> On a des outils comme doxygen. Dans ce cas, il faut documenter enormement, et 
> on se
> retrouve avec ce que je n'aime pas dans le code: de la documentation 
> redondante avec le
> code dans l'hypothese ou le code est bien fait. Et cela est de la 
> documentation de code.
> 
j'ai pas trop apprecier doxygen : je trouve le formatage des
commentaire assez lourd.

Je prefererai un logiciel qui parse le code (regarde directement
les definitions des fonctions) et ensuite genere un fichier html
a partir de ça : reste plus qu'a rajouter les commentaires s'il 
y a lieu.

> On a le cas particulier de cardgame_server qui est capable de generer sa 
> propre doc a
> l'aide de qq fonctions que j'ai faites et qui generent du docbook (sgml) en 
> utilisant
> les variables memes (des tableaux statiques) de son propre code. Ici, seul
> cardgame_server est capable de le faire. On peut tout a fait creer deux 
> binaires, l'un
> pour le serveur et l'autre pour le generateur de doc. Mais une partie du code 
> est
> forcement commune.
> Et je me demande si je ne vais pas quand meme finalement le faire, histoire 
> qu'il n'y
> ait pas de code inutile dans cardgame_server. Mais comprenez bien: ce n'est 
> pas parce
> qu'il y a un generateur de doc utilisant l'implementation du protocole par
> cardgame_server que cette doc devient la doc de reference. Elle reste le 
> niveau
> d'implementation du protocole par cardgame_server.
> 
ok, c'est tres clair comme ca :)

> 
> 
> 
> Une derniere question...
> Il y a dans guide.sgml enormement de commentaires a la fin. Je n'ai pas pris 
> le temps de
> lire ce que c'etait. Peut-on supprimer, ou au contraire, c'est un brouillon 
> pour
> guide.sgml ?
> 
j'avais laisse ces commentaire au cas ou il aurai fallut revenir
en arriere, mais le CVS est la pour ca => on peut les virer.


Philippe

-- 
Philippe Brochard    <address@hidden>
                      http://hocwp.free.fr

-=-= http://www.gnu.org/home.fr.html =-=-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]