Mx: outil de documentation de code source

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
16
jan.
2002
Linux
J'ai le plaisir d'annoncer la publication du projet Mx.

Mx est un outil OpenSource de documentation de code source, qui fonctionne avec de nombreux langages (pour le moment C, C++, Java, Prolog, Qnap, Yacc er Lex).

La grande nouveaute de Mx est que le developpeur travaille non pas sur le code source lui-meme, mais sur les fichiers mx comprenant le source et la documentation. Il devient donc possible de reorganiser son projet en modules.

La documentation produite peut l'etre en HTML ou en LaTeX, avec plusieurs niveaux de documentation (developpeur, utilisateur...)

Ce projet a ete initie par des chercheurs hollandais et il est maintenant continue au National Institute of Informatics de Tokyo, non pas en tant que projet de recherche mais comme outil pour ameliorer la qualite de developpement des logiciels.

Un tutoriel sera rapidement publie sur LinuxFrench.net.

Aller plus loin

  • # hmm

    Posté par  (site web personnel) . Évalué à 10.

    je suis pas vraiment convaincu par les arguments annoncés, d'autant plus que Doxygen en fait pas mal (inclusion de diagrammes, formules mathématiques, génération man, html et latex).
    Et puis le côté "vaut mieux avoir tout le cycle de développement fait en Mx" ça ne m'inspire pas non plus... entre le désir et la réalité, ben...
    Doxygen a le mérite de pouvoir être appliqué instantanément sur des gros projets existants (testé sur le code source de mozilla, c'est plutôt agréable!); il génére des tas de graphiques concernant la structure des données, leur utilisation, etc.

    Bref, un très très bon outil de génération de documentation pour qui programme en
    C/C++ java, IDL (Corba, Microsoft, KDE-DCOP) ...

    A voir : http://www.doxygen.org(...)
    • [^] # Re: hmm

      Posté par  (site web personnel) . Évalué à 5.

      je confirme, passer tout un projet en un nouveau truc qu'on connais pas bcp, c'est pas tous les jours qu'on prend cette decision.
      De plus doxygen marche vraiment pas mal, et pour 2/3 options dans les commentaires en plus tu te crees de la doc sur ton code vraiment pas mal
    • [^] # hmm

      Posté par  (site web personnel) . Évalué à 5.

      Admettons...
      Moi ce qui me dérange le plus, c'est le "le developpeur travaille non pas sur le code source lui-meme, mais sur les fichiers mx comprenant le source et la documentation".
      En cas de bug, tu perds aussi ton code source ?
    • [^] # Re: hmm

      Posté par  . Évalué à 1.

      Doxygen est different, il sert a documenter l'API.

      Mx permet de documenter l'ensemble du projet. C'est particulierement interessant en recherche car il est necessaire de produire des rapports complets.

      Ex:
      "Pour le calcul d'anglogrammes, on utilise l'algo de triangulation de Delaunay propose par [Toto & Tata 98]
      @c
      <le code effectif...>

      @"
      et voila.

      Cela permet aussi de faire de la programmation par aspect, par exemple regrouper dans un meme fichier toutes les methodes concernant l'affichage (meme si ca correspond a des classes differentes, dans l'exemple de C++).

      Cela change fondamentalement la facon de developper, donc je comprends qu'il soit difficile de decider de passer a Mx.

      En realite, si on a recupere le boulot des hollandais c'est simplement parce qu'on en avait besoin ; au NII on ne bosse sur le multimedia donc c'est assez eloigne du theme de recherche.

      Voila, nous ca nous est bien utile alors si ca peut servir a d'autres tant mieux... Maintenant chacun developpe comme il veut, avec doxygen ou sans documenter comme le commentaire modere.
  • # Pas efficace

    Posté par  . Évalué à 1.

    La plupart du temps dans la documentation, ce qui importe, c'est les données et leur signification, l'explication grossière de l'objectif des fonctions (un très bon article sur LMF en parle)

    Les commentaires en plein code (ou l'inverse, d'après ce que j'ai compris de Mx) tendent plutot à rendre le code abscons ; pourquoi vouloir expliquer extensivement avec un langage humain un code naturellement sans ambiguité (S'il ne l'est pas, c'est par la qu'il faut commencer : l'architecture).

    Je vois 2 effets de bord graves à ce principe :
    * Plus on explique le code, moins on éprouve le besoin de le rendre clair à la source
    * Le code perdu dans la documentation, bonjour le debug. Perso, je débuggue visuellement, et la proximité des lignes de codes y joue pour beaucoup.

    C'est une curiosité intéressante, mais pas applicable aux langages actuels.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.