Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Envoyé par Jean-Marc.Bourguet
J'avais donc bien compris le principe: on développe dans trunk, avec des branches éventuelles pour le améliorations /bug fixes, et on produit dans un dossier stable les versions stabilisées, c'est bien ca, hein
A méditer: La solution la plus simple est toujours la moins compliquée
ok. Oui j'ai un peu modifier. Pourquoi?
Trunk c'est le long termeDonc le trunk doit être stable et utilisable.trunk c'est le développement courant. (tu récupéres ça compile)
Comme les participants ne sont pas toujours familier avec svn et qu'il est très difficile de tous contrôler (contrairement à un projet avec des gens dans une même salle), il peut très vite arriver :
* le trunk ne compile plus
* des fichiers ont disparue. Il faut du temps pour remettre en état
* tous ce qui est possible et inimaginable
D'ou la branches/dev. Ça fait tampon. 2-3 personnes remonte régulièrement les modifs vers le trunk, quand le fonctionne est vérifié (compile + test unitaire).
je ne trouve pas cela aussi éloigné de la définition de base, et je trouve cela beaucoup plus sure et le trunk reste stable.
Si tu regarde nos commit pour la mise en place (sur 1 semaine), y as déjà eu des zones où cela ne compilai plus, des choses à modifier, ...
http://projets.developpez.com/projec...tory/revisions
Sa va se stabiliser bien sure, mais si un nouveau participant arrive. Ben on risque de casser le trunk. Et par principe le trunk doit compiler.
Bien vu
Je les précises tout de suite comme suit:
extensions des fichiers.
Quatre extensions sont utilisables en dehors de celles propres aux outils de compilation:
- *.cpp : fichier d'implémentation de fonctions non modèles ou de fonction membre de classe non modèles et non inlinée. Ces fichiers trouvent leur place dans le dossier src
- *.h pour les fichiers d'en-tête. Ces fichiers prennent place dans les dossiers include et dans les sous dossiers de include, autre que impl selon leur utilité
- *.tpp : fichier d'implémentation des fonctions template et des fonctions membres de modèles de classe. Ces fichiers prennent place dans le dossier include/impl
- *.dox : fichier contenant les informations générales permettant la génération autmatique de la documentation avec doxygen. Ces fichiers prennent place dans le dossier doxygen.
Convention de nommage des fichiers
L'implémentation des fonctions non modèles inlines se fait dans le fichier d'en-tête dans lequel elles sont déclarées.
- Les noms de fichiers relatifs à une classe ou à une structures particulières sont nommés du nom de la classe ou de la structure, en respectant la même casse.
- Le nom des fichier d'en-tête et les fichiers d'implémentation spécifiques à une architecture ou à un compilateur sont composés exclusivement de minuscules, en veillant à choisir le nom de manière à rappeler l'objectif de compatibilité à assurer.
- Les noms de fichiers d'en-tête et d'implémentations qui ne se rapportent pas à une classe ou à une structure particulières (par exemple: le fichiers regroupant plusieurs fichiers d'en-tête pour la facilité, ou déclarant / implémentant plusieurs fonctions libres non modèles) sont composés exclusivement de minuscules, en veillant à choisir le nom de manière à rappeler l'objectif poursuivi par le contenu du fichier
L'implémentation des modèles de fonction ou des fonctions membre de modèles de classes peut se faire soit dans le fichier d'en-tête dans lequel elles sont déclarées soit dans un fichier d'implémentation séparé ( *.impl)
Ca, c'est normalement le role des révisions...
Si une révision "casse" le système et que, au pire, tu ne le remarque pas tout de suite, tu remonte de révision en révision jusqu'à trouver le moment où cela recommence à compiler
De toutes manières, tu dois te dire que, si cela arrive, une bonne partie de ce qui a été fait après la révision fautive sera quoi qu'il arrive perdu, surtout si les fichiers modifiés lors de la dite révision fautive ont été remodifiés par la suite
[EDIT] et pour les modifications n'ayant pas porté sur les fichiers modifiés par la révision fautive, il y a toujours la possibilité de récupérer les patches appliqués (ou de récupérer les différences afin d'en déduire les patches à créer pour les appliquer)
Dernier appel avant demande de la création de l'hébergement
Je me propose de choisir dans un premier temps LGPL v3 comme licence (pour que le choix soit fait) et de demander l'hébergement vers 21h00, heure locale (Belgique).
Cela vous laisse donc à peu près deux heures et demie pour donner votre avis sur le nom (Farfelue) et sur la licence (LGPL v3).
Si vous avez de bonnes raisons (autre que simplement celle de nous faire rire un bon coup) à faire valoir sur ces deux points, c'est le moment, c'est l'instant
Pour les remarques n'ayant pas trait à ces deux points particuliers, la discussion reste bien entendu ouverte
Merci de votre compréhension
[EDIT]La version la plus à jour du document est disponible
Concernant les commentaires, se limiter à // « pour pouvoir désactiver du code avec /* */ » est inutile : on peut désactiver du code avec #if 0 ... #endif (et Kate et Vim le colorent d'ailleurs comme les commentaires).
Sur les fichiers, vous voulez un fichier par classe, ou des modules un peu plus gros?
Je dis cela parce que les IHM que j'ai vues avaient tendance à avoir pléthore de classes minuscules (et notre idée de fonctionner par classes de traits ira dans ce sens).
Il me semble qu'on devrait tenter de trouver un équilibre entre les 2993 fichiers de 17 lignes, et les 20 fichiers de 2300 lignes... Une fois de plus, je vois mieux dans ce domaine des "déclarations de politique générale" que des règles strictes, mais ca peut être le bon moment pour en parler...
[EDIT] je suis pour le nom (ben forcément...) et pour la LGPL v3...
Francois
De toutes manières, je le répète, le code désactivé est proscrit lors du commit.
Tout ficher commité avec du code désactivé, que ce soit à coup de #if 0 ou à coup de commentaire sera "flingué à vue"
A bon entendeur
Effectivement, il faut en parler.
La politique générale sera d'éviter les fichiers définitivement trop petit (je me vois mal maintenir un fichier qui ne contient qu'une classe vide qui sera utilisée comme flag dans une politique) mais d'éviter également d'avoir un fichier contenant 3 classes de 500 ou 1000 lignes chacune.
Je crois donc que la politique officielle sera "nous verrons au coup par coup s'il est utile / opportun de scinder ou de fusionner les fichiers décidément fort proches"
Il va de soi que si deux classes n'ayant rien à voir entre elles sont déclarées dans un même fichier, le fichier sera scindé
Cela ne sera cependant pas le cas des commentaires (enfin, j'espèreDe toutes manières, je le répète, le code désactivé est proscrit lors du commit.
Tout ficher commité avec du code désactivé, que ce soit à coup de #if 0 ou à coup de commentaire sera "flingué à vue"
A bon entendeur
Mon avis là-dessus est qu'il n'y a aucune raison de ne pas utiliser les commentaires /* */.
Et comme je l'ai précisé, je suis moi même assez friand des commentaires multilignes
Aussi, à moins que l'on m'apporte d'excellentes raisons pour refuser l'une ou l'autre des possibilités de commentaires, je ne pense pas les interdire.
Au contraire, je préférerais avoir les commentaires mis entre /* et */ avant les instructions que de les avoir sous la forme uniligne, avec rappel systématique du // au début de la ligne.
Mais bon, comme je n'ai moi-même aucune raison "valable" d'imposer cette vision des choses, je préfères laisser la possibilité d'utiliser les deux formes... du moins, dans un premier temps
Ceci dit, les commentaires sont, certes, autorisés et même encouragés, la limite reste toujours qu'ils doivent être contributifs et sensés.
Je préfères presque ne pas avoir de commentaires que d'avoir des commentaires inutiles, tels que celui que je donne dans l'exemple sur le sujet
Pareil, j'ai tendance à penser qu'un commentaire doit soit être court, soit être absent... Les commentaires trop longs deviennent faux encore plus vite que les courts...
Sur tous ces points, je pense que le premier "fil" qu'on ouvrira sur redmine devrait être un fil "politique générale", permettant de définir, et éventuellement, de réviser, nos opinions communes sur ces différents points. A terme, en compilant tout cela, on arrivera à nos règles de codage, qui auront l'avantage d'être éprouvées (plutôt que ces trucs qu'on finit par regretter mais qu'on conserve parce qu'elle étaient là au début...)
Dans la même veine, je pense qu'il nous faudra également un fil "techniques C++" qui permet de décider ce qu'on considère comme "malin", et ce qu'on considère comme "tordu"... S'en tenir à un morceau homogène, cohérent et stable du langage (et des libs qui vont avec), c'est un bon moyen de garder le code maintenable.
Je verrais bien également un fil algo, sur le même principe.
Là encore, le but n'est pas réellement d'imposer des règles strictes, mais d'arriver ensemble à un corpus de bonnes pratiques.
Francois
Il y aura effectivement un grand nombre de choses à affiner et à prévoir, et tout cela devra effectivement faire l'objet, si pas d'une décision unanime, au minimum d'un compromis cohérent
Et je suis sur que nous aurons également une foule d'autres problèmes auxquels on ne pense pas forcément à l'instant, et dont il faudra débattre en temps opportun
Comme je l'ai indiqué dans le document que je vous présente, il ne sera sans doute pas dans sa version définitive avant la sortie de la première version de production de la bibliothèque.
Cependant, ce sera sans doute le document de référence sur lequel l'ensemble des développeurs devront se basé pour connaitre les différents tenants et aboutissants.
Je me chargerai de le maintenir à jour chaque fois qu'une décision est prise concernant la politique générale et la politique particulière concernant le projet
Edit : Cela me fait penser que j'aurais en fait du, pour de simples raisons de cohérence de version, commencer à le numéroter en 0.0.xx afin de passer en version 0.5.xx une fois l'objectif prioritaire attient et en version 1.xx.yy en une fois la bibliothèque mise en production
Je renuméroterai mes documents lorsque je les présenterai sur le site du projet
Je suis le seul que ça choque des fichiers d'entêtes en .h? Je sais que c'est assez commun dans le monde du C++. Mais justement, on utilise cpp, alors pourquoi pas hpp? Dans tout mes projets j'ai que du hpp.
M'enfin, c'est pas la fin du monde :p.
Sinon +1 pour le nom, et euh la license comme vous voulez :p
"Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu
Ça ne me choque pas -- tellement peu que je n'aurais pas commenter si tu ne l'avais pas fait -- mais je préfère effectivement hpp (en réservant h à ce qui passe aussi en C)
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
à vrai dire, je serais également d'avis d'utiliser de préférence *.hpp, mais si je prend CodeBlocks (qui est l'EDI que j'utilise le plus volontiers sous windows) par exemple, force est de constater que, par défaut, il propose d'utiliser l'extension *.h
Le fait de forcer à l'utilisation de *.hpp nécessiterait pour les contributeurs qui l'utilisent de "perdre leur temps" à modifier chaque fois qu'ils font appel, par exemple, au dialogue de création d'une classe, non seulement pour le fichier d'en-tête de la classe qu'ils créent, mais également pour le fichier d'en-tête inclus en cas d'héritage.
Si je suis le seul à trouver cette "perte de temps" dommage et que vous préférez indiquer clairement qu'il s'agit d'en-tête C++ en utilisant l'extension hpp, je reste cependant disposer à modifier les règles en ce sens
Comme je l'ai dit, l'idée est dans un premier temps de lancer le projet, et de "rassurer" les gestionnaires de l'hébergement.Sinon +1 pour le nom, et euh la license comme vous voulez :p
Le changement de licence peut très facilement être envisagé en cas de besoin aussi longtemps que nous n'en somme pas à la phase de production proprement dite.
Et même au delà, le changement de licence reste envisageable, même s'il est préférable de le faire lors de l'annonce d'une version stable
Le changement de nom, par contre, serait beaucoup plus problématique
Ben tu explique bien la complexité. Quand c'est un projet interne, Cela ne pose pas de problème.Ca, c'est normalement le role des révisions...
Si une révision "casse" le système et que, au pire, tu ne le remarque pas tout de suite, tu remonte de révision en révision jusqu'à trouver le moment où cela recommence à compiler
De toutes manières, tu dois te dire que, si cela arrive, une bonne partie de ce qui a été fait après la révision fautive sera quoi qu'il arrive perdu, surtout si les fichiers modifiés lors de la dite révision fautive ont été remodifiés par la suite
[EDIT] et pour les modifications n'ayant pas porté sur les fichiers modifiés par la révision fautive, il y a toujours la possibilité de récupérer les patches appliqués (ou de récupérer les différences afin d'en déduire les patches à créer pour les appliquer)
Quand n'importe qui peut accéder au trunk(public), le problème est différents.
Et dans ce cas, je préfère une zone tampon qui la zone de dev principale et un trunk soigneusement mise à jour par 2-3 personnes. Je pense que c'est là où git apporte un grand intérêt. On peut accepter/refuser les commits.
Au pire, le trunk peut toujours redevenir la branch principale de dev.
Mes deux cents.
Pour travailler régulièrement sur des projets portables entre des plateformes case-sensitives et des plateformes case-insensitive, mixer les casses dans le nom des fichiers est assez casse-gueule et source de pas mal de problème.
Je pense qu'il est préférable de n'utiliser que des minuscules dans le nom de fichier même dans ce cas de figure.
Bien vu...
Je modifie donc en conséquence
casse. enLes noms de fichiers relatifs à une classe ou à une structures particulières sont nommés du nom de la classe ou de la structure, en respectant la même
Nota: les changements proposés et accepté dans le document de base ne seront, à partir de maintenant, plus fournis ici dans une nouvelle version du pdf.es noms de fichiers relatifs à une classe ou à une structures particulières sont nommés du nom de la classe ou de la structure, tout en minuscule.
La prochaine version (0.1.4, afin de respecter la cohérence des version) du pdf sera disponible sur le site du projet dés que j'aurai l'hébergement et intégrera l'ensemble des corrections apportées
Je n'ai pas forcément tout lu, mais je suggère dans la liste des features la possibilité d'intégrer une fenêtre Farfelue dans une fenêtre d'un autre langage (un peu comme le QWinMigrate de Qt).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager