Salut la foule, c'est vendredi : c'est permis !
Je bosse dans le domaine du web : je crée des applications mais j'en intègre aussi. Lorsque je crée une application, je pense, en codant, au pauvre gus qui risque d'aller voir le code pour modifier l'appli. Pour que ce pauvre gus s'y retrouve, je place en en-tête quelques commentaires décrivant le "but" du script, si ce script dépend d'autres scripts (et lesquels) ainsi que la liste des fonctions/classes qu'il définit et la version minimale pour laquelle ce script est créé (pour php). Dans le code, à chaque action faite, à chaque ligne presque, je place un commentaire qui explique comment fonctionne la fonction, pourquoi je fais faire telle ou telle chose... ainsi, si quelqu'un va voir le code, il saura à quoi il sert...
Depuis quelques jours, j'intègre wordpress-mu à un environnement existant (ayant son propre mode d'authentification, par exemple) et pour se faire, je suis obligé de reprendre chaque étape de chaque action, de noter sur un papier la liste d'appels de fonctions, les noms de variables, la liste des dépendances... et c'est usant...
aucun commentaire dans le code sauf "// TODO : must translate this string" (super utile hein ?) ou "get_footer(); // get the footer" (tout aussi utile) ou encore (mon préféré) "// this is ugly !"
Mon coup de gueule : ok il ya une doc (très incomplète) ok la version MU est jeune mais quand même... ça serait quand même bien plus simple de commenter le code non ? C'est bien d'ouvrir un code et de vouloir que la communauté soit active dans le projet, mais, à mon sens, libérer du code ça passe aussi par donner les moyens aux autres de le modifier "simplement" sans qu'ils aient à chercher pendant des heures à quoi sert telle ou telle fonction apparemment cruciale...
Est-ce que j'en demande trop ?
Je bosse dans le domaine du web : je crée des applications mais j'en intègre aussi. Lorsque je crée une application, je pense, en codant, au pauvre gus qui risque d'aller voir le code pour modifier l'appli. Pour que ce pauvre gus s'y retrouve, je place en en-tête quelques commentaires décrivant le "but" du script, si ce script dépend d'autres scripts (et lesquels) ainsi que la liste des fonctions/classes qu'il définit et la version minimale pour laquelle ce script est créé (pour php). Dans le code, à chaque action faite, à chaque ligne presque, je place un commentaire qui explique comment fonctionne la fonction, pourquoi je fais faire telle ou telle chose... ainsi, si quelqu'un va voir le code, il saura à quoi il sert...
Depuis quelques jours, j'intègre wordpress-mu à un environnement existant (ayant son propre mode d'authentification, par exemple) et pour se faire, je suis obligé de reprendre chaque étape de chaque action, de noter sur un papier la liste d'appels de fonctions, les noms de variables, la liste des dépendances... et c'est usant...
aucun commentaire dans le code sauf "// TODO : must translate this string" (super utile hein ?) ou "get_footer(); // get the footer" (tout aussi utile) ou encore (mon préféré) "// this is ugly !"
Mon coup de gueule : ok il ya une doc (très incomplète) ok la version MU est jeune mais quand même... ça serait quand même bien plus simple de commenter le code non ? C'est bien d'ouvrir un code et de vouloir que la communauté soit active dans le projet, mais, à mon sens, libérer du code ça passe aussi par donner les moyens aux autres de le modifier "simplement" sans qu'ils aient à chercher pendant des heures à quoi sert telle ou telle fonction apparemment cruciale...
Est-ce que j'en demande trop ?
> Lire le journal (54 commentaires, moyenne: 4,7).
Vous avez demandé le commentaire #844473.
Run by 
Cette page a été générée par Templeet en 0.052s (dont 0.0054 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Ça pourrait être pire ..
Ça pourrait être du code fermé ...
Moi par exemple, cette semaine, je dois utiliser une bibliothèque Java qui m'est fournie dans une application que je développe. Évidemment, je n'ai pas accès au code, j'ai juste le droit à une javadoc, et un fichier au format Microsoft Word qui décrit le bouzin. Première bonne surprise, le fichier en question contient un schéma d'architecture plutôt léger et visiblement faux, deux trois paragraphes probablement écrits par quelqu'un qui n'a pas participé au codage de la bibliothèque (et sans doute avant qu'elle existe) et plusieurs page de description de l'API qui ressemble à la javadoc, mais en moins complet.
La javadoc, doxygen et leurs copains, c'est bien à condition que l'on décrive un minimum les API. Hors la je n'ai que des choses du genre :
et bien souvent avec des noms moins explicites.
Finalement, pour comprendre quelque chose, et pour vérifier mes suppositions, j'ai décompilé le code. Ce n'est pas parfait, mais ça aide bien ! Une chance qu'ils n'aient pas pensé à l'obfusquer.
[^]Re: Ça pourrait être pire ..
Ca me rappelle une des mes expériences. J'ai récupéré un projet d'interfaçage avec un soft d'un très gros éditeur de logiciels financiers.
La doc : un gros PDF qui ressemble à de la javadoc mais qui n'en n'est pas - et ça se voit, c'est pas à jour. Quand je demande la javadoc, on me dit "oui oui", mais ça ne vient jamais.
Je me dis que je vais la générer moi-même en décompilant la lib, mais pas de chance, elle est obfusquée. Du coup, lorsque je croise des bugs, la pile d'appel n'apporte aucune information utile que je puisse transmettre à leur support...
Et comme il n'ont pas respecté les conventions java (les méthodes commencent par une majuscule, les paramètres par des "p", etc.), la complétion ne marche plus dès que je tape le premier caractère d'une méthode (sauf si je pense à la taper en majuscule bien sûr).
Ils ont développé leur propre mini-framework de logging qui est compatible avec rien, et d'ailleurs ils ne l'utilisent pas toujours, ça va des fois directement dans SystemOut.
Que du bonheur...
Et il y en a encore : un système de licence contraignant et inutile, un "bugzilla" antédilluvien et bien sûr maison, une compatibilité avec uniquement certaines versions de JVM (java 1.4 maxi), etc.
Non, rien.
[^]Re: Ça pourrait être pire ..
Si ça peut- t'aider, ça ce décompile très bien le Java.
Tu perds entre autre les commentaires... mais comme dit un peu partout ici, ils sont rarement intéressants de toute façon.
[^]Re: Ça pourrait être pire ..
Pardon... Je sors chercher des orties pour me flageller en répétant qu'il faut tout lire avant de répondre.