Discussion :

[Invité]

Tu parle de farelUI, ou de farfelue

farfelu(e)

Francois

[koala01]

Bon, pendant que vous vous "chamailliez" sur le nom de la bibliothèque, je viens de passer un certain temps à pondre un premier document de travail qui reprend ce qui a été dit et qui énonce certaines règles.

Il s'agit d'une toute première version qui risque non seulement d'évoluer avant que je n'aie demandé l'hébergement, mais qui risque également d'évoluer par la suite afin de refléter au mieux l'ensemble des décisions qui feront la philosophie du projet.

Pour l'instant, je me suis basé sur le nom farfelue, mais ce n'est encore qu'à titre indicatif.

Pouvez vous me donner votre avis sur ce document, sachant que les grandes lignes resteront identiques

Pour ceux qui envisagent l'idée de participer, acceptez vous les règles énoncées

[yan]

Quelques remarques (lue rapidement):

• T sur les classe template : vue l'objectif, il va y en avoir partout, non?
• membre préfixé par _ : ma maman ma toujours dit que c'est pour le compilot...
• trunk : pour moi c'est plutôt quelques choses de stable. Un truc que tu récupère et qui compile. Nous on fait un branche pour le dev

voici ce que l'on as mis en place pour le svn, les règles de codage et doxygen (en cours de finalisation). Ca peut surement te servir :
http://projets.developpez.com/projects/qextend/wiki

Pour la mise au propre du style de code, il existe Artistic Style d'assez puissant.

[koala01]

Quelques remarques (lue rapidement):[*]T sur les classe template : vue l'objectif, il va y en avoir partout, non?

il risque en effet d'y en avoir une sérieuse chiée... Mais cela permettra à tout le monde de se rendre compte que la classe qu'il souhaite utiliser est un template

[*]membre préfixé par _ : ma maman ma toujours dit que c'est pour le compilot...

C'est pour cela que je parle de les... suffixer par _

[*]trunk : pour moi c'est plutôt quelques choses de stable. Un truc que tu récupère et qui compile. Nous on fait un branche pour le dev

On peut changer le nom pour faire comme ce qui est habituellement fait (j'ai été un peu vite sur ce coup là )

voici ce que l'on as mis en place pour le svn, les règles de codage et doxygen (en cours de finalisation). Ca peut surement te servir :
http://projets.developpez.com/projects/qextend/wiki

je vois que les conventions que je préconise sont fort proches

Je vais modifier assez rapidement certains points (par contre, je ne crois pas vraiment que l'alignement des noms de membres soit indispensable )

Pour la mise au propre du style de code, il existe Artistic Style d'assez puissant.

Bien vu... ca peut faciliter le travail

[Invité]

Je suis assez d'accord sur les règles générales... Il faudra probablement définir plus précisément les règles de nommages (d'expérience, ca aide beaucoup à se retrouver dans le code).

Une petite remarque sur les commentaires, je pense qu'il est bon de proposer que tous les commentaires soient C++-style (// Mon commentaire). Ceci permet, en phase de debug, de commenter des bouts de code par /* sans se poser de questions sur les imbrications... Au commit dans svn, en revanche, on tire à vue sur le /*, intrusif...

Autre petit point, je pense qu'il faudrait, au démarrage, proposer une installation unique et commune sur tout l'équipe projet. Gcc qqchose, ou VS machin truc, une version de STL et de boost, etc... Je dis cela parce que d'expérience, on se galère vite en incompatibilités de compilos (surtout si on veut employer des normes récentes et des libs évolutives)

Après, bien sur, on changera d'avis, mais au début...

(Et je dis cela la mort dans l'ame, car moi, je fais du borland, m'sieurs-dames...)

Francois

[yan]

(par contre, je ne crois pas vraiment que l'alignement des noms de membres soit indispensable )

Je trouve cela plus facile à lire et moins agressif pour l'oeil.

Pour les membres, pour moi _ sert à montrer quelques choses d'important. Par exemple une variable membre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

m_variable

.Il n'y as pas d'ambiguïté.
Alors que mVariable pourrai faire penser à une variable matrice (si on se trouve avec du code qui préfixe le type de la variable... ). Qu'il soit préfixé ou suffixé, ça me gêne. J'ai l'impression qu'il manque quelques choses.

Mais bon les goût et les couleurs... tant que c'est moi qui choisie, ca ne me pose pas de problème

[Invité]

Autre point, après avoir lu les règles de codage de QExtend...

Nos écrans sont plus larges que hauts, on ne veut pas de lignes trop longues, mais la coupure d'une instruction (if, for, un appel ou une déclaration de fonction doit être l'exception et la norme.

Du code comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
if 
(
    a < b
    || 
    c > d
)
{
    a = 1 
        + 
        foo()
        + 
        (
            bar() 
            - 
            10
         ) 
         / 
         10 ;
}

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if ( a < b ||  c > d ) {
    a = 1 + foo() + (bar() - 10) / 10 ;
}

me donne toujours l'impression d'avoir été écrit par un bègue...

Pour le reste, j'aime pas les blancs, mais je m'y mettrai, ad majorem farfelui gloriam.

Francois

[Goten]

Quelques remarques (lue rapidement):

• T sur les classe template : vue l'objectif, il va y en avoir partout, non?
• membre préfixé par _ : ma maman ma toujours dit que c'est pour le compilot...
• trunk : pour moi c'est plutôt quelques choses de stable. Un truc que tu récupère et qui compile. Nous on fait un branche pour le dev

trunk c'est le développement courant. (tu récupéres ça compile). branch pour les gros changements qui doivent être fait en parallèle. Et c'est tag pour la partie figer...

[yan]

me donne toujours l'impression d'avoir été écrit par un bègue...

Moi non plus j'aimais pas au début. Mais quand quelqu'un relit le code, c'est pas si mal. Et si le calcul ou l'opération est complexe, on peut facilement ajouter du commentaire.
L'exemple est un extrême, faut pas faire cela partout.

Toutes façon, les règles de codage sont rarement suivie à la lettre. Donc autant être le plus stricte possible dans les textes pour avoir un code qui s'en approche.

[koala01]

Je suis assez d'accord sur les règles générales... Il faudra probablement définir plus précisément les règles de nommages (d'expérience, ca aide beaucoup à se retrouver dans le code).

J'en ai peut être oublié, mais lesquelles Si je reprend, on a:

• les classes MaClasse
• les structure MaStructure
• les unions MonUnion
• les énumération eMonEnumeration
• les valeurs énumérées meValeur
• les valeurs énumérées dans les énumérations anonymes valeur
• les membres privés de classe : membre_ (on peut généraliser à "membres privés" )
• les champs public de structures et d'union : membre (on peut généraliser à "membre publiques")
• les arguments et variables : mavar
• les arguments au constructeur membre_ (si besoin)
• les noms de fonction doSomething, doSomethingElse

J'ai effectivement oublié les gardes anti inclusion multiples et les accesseurs (donnee() const ), que je rajoute, mais, à part cela

Une petite remarque sur les commentaires, je pense qu'il est bon de proposer que tous les commentaires soient C++-style (// Mon commentaire). Ceci permet, en phase de debug, de commenter des bouts de code par /* sans se poser de questions sur les imbrications... Au commit dans svn, en revanche, on tire à vue sur le /*, intrusif...

Je vais en tout cas préciser que le code du commit doit être purgé de tout code désactivé (car on peut aussi simplement vouloir désactiver une seule ligne )

Par contre, j'aime assez écrire mes commentaires sur plusieurs lignes sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
/* maFonction : fonction qui fait ce que j'attend d'elle
 * @in  : arg 1 le premier arguement
 *        arg2 le second argument
 * @out : le type de retour
 * @throw : exception1 si machin
 *          exception2 si truc
 */

ou sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void foo()
{
    /* j'ai une information importante à donner sur cette partie du code
     * et je prend plusieurs lignes pour le faire
     *
     * Ca permet au lecteur de le remarquer assez facilement :D
     */
}

Mais je me plierai à la majorité, sur ce coup là

Autre petit point, je pense qu'il faudrait, au démarrage, proposer une installation unique et commune sur tout l'équipe projet. Gcc qqchose, ou VS machin truc, une version de STL et de boost, etc... Je dis cela parce que d'expérience, on se galère vite en incompatibilités de compilos (surtout si on veut employer des normes récentes et des libs évolutives)

Je suis tout à fait d'accord en ce qui concerne boost car si quelqu'un arrive avec la version 1.24, on risque d'avoir du mal

Par contre, je me dis que l'on risque d'être mal barré s'il s'agit de forcer à une installation commune, même si j'admets sans peine que cela permettrait d'éviter bien des soucis.

Personnellement, je travaille avec une version perso de... gcc-4.5.0 compilée avec le support de multilib ...

Je peux, effectivement, diffuser cette version (et je l'ai déjà fait lorsque j'ai proposé une version de Qt compilée avec ), mais de là à forcer tout le monde à l'utiliser, je voudrais être sur que ce soit d'accord pour tout le monde (en plus, il faut penser à ceux qui sont sous linux )

Après, bien sur, on changera d'avis, mais au début...

oui, oui, je comprend bien

(Et je dis cela la mort dans l'ame, car moi, je fais du borland, m'sieurs-dames...)

Francois

Pôôvre malheureux... je compatis

[yan]

trunk c'est le développement courant. (tu récupéres ça compile). branch pour les gros changements qui doivent être fait en parallèle. Et c'est tag pour la partie figer...

? y as un problème sur le fonctionnement du svn ?

[Jean-Marc.Bourguet]

Quelques remarques (lue rapidement):

• membre préfixé par _ : ma maman ma toujours dit que c'est pour le
  compilot...

C'est un peu plus complique que cela. C'est la regle que je donne et que
j'applique, mais il y a a des exceptions; la seule que je retiens est
justement qu'un _ suivit d'une minuscule est conforme comme membre.

[quote]

• trunk : pour moi c'est plutôt quelques choses de stable. Un truc que tu récupère et qui compile. Nous on fait un branche pour le dev

Trunk c'est le long terme. Les branches sont soit

• pour des projets qui par nature destabiliserait trunk ou qu'on veut
  tester avant de decider si ca part ou pas
• pour la stabilisation avant release et la maintenance.

En gros plus c'est branche profond, plus c'est temporaire.

J'en ai peut être oublié, mais lesquelles Si je reprend, on a:

• les classes MaClasse
• les structure MaStructure
• les unions MonUnion
• les énumération eMonEnumeration

Pourquoi mettre les enum a part des autres types? On peut finir par
vouloir wrapper l'enum dans une classe et devoir alors tout renommer ou
garder une inconsistance.

[koala01]

Pour ce qui est de la césure des expressions, je suis assez compliqué

Je n'aime personnellement pas les expression dans lesquelles chaque terme est sur une nouvelle ligne, mais je trouve également très compliqué d'avoir trente-six termes illisibles sur une seule et même ligne.

Mon approche sera donc (en gros):

• Césure en ca de besoin après une parenthèse ouvrante, une virgule ou un des opérateurs logique ( &&, ||, ^, &, |,...)
• Césure dés qu'il y a plus de deux termes à évaluer
• Alignement des termes à évaluer

Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
if( i == 1 && j == 2 ) // pas de césure
if( ( i == 1 && j == 2 ) || // regroupons les termes de manière cohérente
    ( i == 3 && j == 4 ) )
{
}
for_each( machin_tres_long_quasi_illisible_par_lui_meme.begin(),
          machin_tres_long_quasi_illisible_par_lui_meme.end(),
          bind2nd( brol,
                    valeur )
         );

Je vais en outre rajouter les règles (qui sont appliquées dans mon exemple)

• utilisation des parenthèses lorsque des règles de priorité risquent de modifier l'ordre d'évaluation des opérateurs
• un espace après la parenthèse ouvrante
• un espace avant la parenthèse fersmante
• un espace avant et un espace après les opérateurs
• un espace avant et un espace après les indicateur de pointeur et de référence ( char * tab ou Type const & ref);
• un espace après la virgule s'il n'y a pas césure

Pour les membres, pour moi _ sert à montrer quelques choses d'important. Par exemple une variable membre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
m_variable

.Il n'y as pas d'ambiguïté.

J'avoue avoir hésiter longuement (et continuer à le faire ) sur la meilleur manière de présenter les membres privés...

Ce qui m'embête le plus avec le fait de les préfixer (que ce soit par m_ ou par _), c'est que cela les regroupe systématiquement tous dans un intellisens.

Par contre, si on les suffixe (par exemple uniquement avec _), tu obtiens la possibilité de les trier "naturellement":
avec un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class MaClass
{
    public:
        int value() const{return value_;}
    private:
        int value_;
};

si tu écris obj.val, l'intellisens te propose directement value_ et value, alors que si tu préfixe tes membres par m_, avec trois lettres introduites, l'intellisens risque encore de te donner beaucoups d'autres membres commençant par m_v

[koala01]

Pourquoi mettre les enum a part des autres types? On peut finir par
vouloir wrapper l'enum dans une classe et devoir alors tout renommer ou
garder une inconsistance.

Bien vu...

Simplifions donc la règle afin que tout type personnalisé (exception faite des classes template) suive les même regle de nommage

[Jean-Marc.Bourguet]

Simplifions donc la règle afin que tout type personnalisé (exception faite des classes template) suive les même regle de nommage

On (moi compris) a tendance a utiliser classe template pour "class template" mais une meilleure traduction est "template de classe". Les templates de classe ne sont pas des types mais des templates. Les specialisations (non partielles) de templates de classe sont des types.

[koala01]

On (moi compris) a tendance a utiliser classe template pour "class template" mais une meilleure traduction est "template de classe". Les templates de classe ne sont pas des types mais des templates. Les specialisations (non partielles) de templates de classe sont des types.

Il faudrait donc aller encore plus loin et parler de "classes modèles" ...

Mais je prend la remarque en compte

[Jean-Marc.Bourguet]

Il faudrait donc aller encore plus loin et parler de "classes modèles" ...

Je crois que tu as manque le point (ou tu aurais ecris "modeles de classes"): ce ne sont pas des classes et donc ne pas leur appliquer les conventions de nommage des classes ne me gene pas fondamentalement. Mais il faudrait mieux appliquer les memes convensions aux templates (ou modeles ou patrons) de fonctions.

Et la ca me gene. La deduction des parametres fait que j'ai tendance a considerer que le fait qu'il s'agit d'une instantiation de template ou non est un detail d'implementation.

Ca me gene tellement que je me demande si pour tous les templates il ne vaut mieux pas appliquer les conventions de la categorie instantiee. Ca apres tout, qu'est-ce qu'une difference de conventions de nommage apporterait ici?

[koala01]

Je crois que tu as manque le point (ou tu aurais ecris "modeles de classes"): ce ne sont pas des classes.

C'est surtout mon clavier qui a fourché sans mon consentement... je voulais bel et bien parler de "modèle de classe"

D'ailleurs, c'est bel et bien ainsi que je l'ai présenté dans le document dont je vous fournis une version mise à jour

[Goten]

? y as un problème sur le fonctionnement du svn ?

Je répondais juste à ça :

# trunk : pour moi c'est plutôt quelques choses de stable. Un truc que tu récupère et qui compile. Nous on fait un branche pour le dev

J'ai peut être mal interprété ce que tu disais. Mais pour moi c'est pas ça...

(cf la remarque de Jean Marc qui a été plus loin que moi dans l'explication)

[Invité]

J'ai aussi l'impression qu'il manque une convention sur les noms de fichiers(casse, extensions)