(Courriels de diversion: <vouerai@relies-tricherai.com> <ridiculiserai@ressemblerions-jumellerais.com> <epouse@capes-coquettes.com> <trafiquee@cauterisation-mobiliers.com> <defibrer@terminez-peignes.com> <programmais@remplirons-rassasiez.com> <enregistrerait@entierete-dialectique.com> <coloniserons@soupconnee-rurale.com> <periclita@budgetisation-bloques.com> <inspiree@annexees-avilis.com> )
Selon fa.vdb@free.fr: > Comme suite à mon précédent mail (qui est sans réponse, sauf nath), j'ai > entrepris le toilettage des programmes. Désolé de ne pas avoir répondu à ce mail plus tôt. > A cette occasion j'ai effectué une > re- > écriture visant à supprimer la fonction ouvrir_cfg. Ah ? Première nouvelle. Il me semble qu'ouvrir_cfg ne doit pas être supprimé mais réécrit afin de prendre en compte la conformité au Linux File System comme cela a commencé à être débroussaillé sur cette liste sous l'impulsion de Guilhem. On n'est pas très riche en ressources de développement. Ce serait dommage qu'on soit 3 à recoder la même fonction et que le 4ème dise aucune de vos propositions ne me convient ;-) > J'ai normalisé l'écriture > générale selon les principes suivants : Avant d'appliquer des principes, il faudrait se mettre d'accord dessus. > - indentation : par tabulation (non remplacé par des espaces) Mauvaise idée. Le mélange d'espaces simples et de tabulations est une source d'illisibilité car il n'y a pas de standard parfaitement établi d'interprétation des tabulations. Le plus répandu sous Unix est que le pas de tabulation est de 8 espaces simples. C'est inapplicable dans du code structuré. Donc chacun utilisant les tabulations les interprète à sa façon ou en laisse lâchement le soin à son éditeur préféré. J'ai réglé ce problème en mettant dans ma configuration de vim : se tabstop=999 Ca m'évite que mon éditeur préféré me mette des tabulations sans que je le lui demande (chose que je ne souhaite jamais dans du code). > - les crochets : commence en colonne identique à l'élement auquel il se > rapporte, l'identation s'applique à la ligne suivante Je suppose que tu veux parler des accolades. Cette règle est raisonnable ... mais pas universelle. Donc à débattre. Perso, je n'en ferai pas un fromage. > - les commentaires : s'aligne sur la colonne d'indentation correspondante Ca paraît louable. Le point essentiel à mon avis est que : 1- des règles soient clairement définies et approuvées par les contributeurs, puis publiées 2- les règles définies puissent être mises en oeuvre par un outil tel que "cb" (C beautifier). A défaut de ce consensus, il convient de suivre les règles implicitement mises en oeuvre dans l'état du module que l'on reprend. > Pour l'instant je n'ai rien chargé sur le CVS. Ce soir je mettrai sur mon > site > perso la nouvelle rédaction de la fonction main dans synthese.c (visant à la > > suppression de ouvrir_cfg). J'ai hâte de voir ça. Il me semble temps de faire de la conception sur ce projet. Le bricolage par 1 personne, voire 2, c'est vivable. Mais à 4, on ne va pas y arriver. Donc, il faut créer sous CVS : - 1 liste des tâches issues d'une spécification de besoin - pour chaque tâche, la conception envisagée, le développeur/responsable de la tâche, le délai de livraison prévu, les contraintes d'ordonnancement par rapport à une autre tâche, les sources impactés (un redécoupage de certains fichiers dont util.c est très probablement souhaitable) > Il faudrait se décider sur les version (0.3.x et 0.4.x) et leur mode de > fonctionnement (qui charge, qui valide). Jusqu'ici, Roger livrait et je validais et intégrais nos modifs respectives et quand un niveau stable paraissait atteint, un "tag" (version stable) était posé pour un ensemble cohérent. En principe, la définition des objectifs d'une version se trouve sous : http://www.culte.org/projets/biglux/devel/lao/todo.shtml C'est vrai qu'actuellement, la prochaine version n'y est pas définie. D'où l'urgence d'inventorier les tâches . Ensuite, et seulement ensuite, on peut choisir les tâches par ordre de priorités et de disponibilités envisageables qui devront être accomplies pour la définition des futures versions (... sachant que Roger a parlé d'un gel des évolutions de LLiaPhon mais ça se discute aussi). Franz, es-tu volontaire pour initier ces pages sous CVS (répertoire BigWeb, a priori) de : - règles de codage et leur instrumentation - recensement des tâches - conception existante (Roger ?) et future (tous) Charge ensuite à chacun de les faire vivre selon ses compétences et envies. (Un Wiki serait peut-être plus adapté/dynamique ... mais on n'en n'a pas (encore) sous la main.) A nos marques ! N'est-ce pas Roger ? Au passage, il me paraît souhaitable que Guilhem puisse s'exprimer sur ces pages sous CVS ce qui n'est pas encore le cas. N'est-ce-pas, Nath ? Cordialement. -- Phil