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
- Mx Project (7 clics)
- NII (3 clics)
# hmm
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
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 Emmanuel Blindauer (site web personnel) . Évalué à 5.
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 VACHOR (site web personnel) . Évalué à 5.
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 Erwan . Évalué à 1.
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 Jean-Noël Avila . Évalué à 1.
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.