Discussion :

[Kaluza]

Bonjour à tous.

J'aimerai être au point sur les "naming convention" les plus répandues en C++. Enfin disons que j'aimerai surtout éviter d'adopter un style exotique pour certaines choses "par hyper répandues" et pour lesquelles on ne trouve pas forcément de règles bien établies. Donc pour chaque question qui va suivre, c'est plutôt dans le sens "quel est le style qui n'est jamais utilisé ?" que "quel est le meilleur style de la mort qui tue trop stylé?" qu'il faut la lire. Alors selon vous quel est le style à adopter, ou plutôt celui à exclure pour :

1) Les abréviations dans les noms qui doivent être normalement en majuscules : MyCRTPClass ou MyCrtpClass ?

2) Les paramètre template : plutôt template<class TYPE1, class TYPE2> ou template<class Type1, class Type2> ? Et si le premier cas n'est jamais utilisé (c'est celui que j'utilisais jusqu'à présent en fait), y-a-t-il une convention qui permet de différence un paramètre template d'un nom de classe ?

3) Les typedef de paramètres template (pour une classe de Traits par exemple) les typedef en général : une suggestion de notation "relativement" utilisée ?

4) Les variables locales : my_local_variable ou myLocalVariable ou encore autre chose ? (j'ai l'impression que le premier est de moins en moins utilisé, mais c'est peut être qu'une impression).

5) Pour les variables membres : _myDataMember vs myDataMember_ vs myDataMember vs mMyDataMember vs m_myDataMember ? (le cas 1 est différent des notations compilos car c'est une minuscule qui suit le "_" : personnellement c'est celle que j'utilise mais je ne sais pas si c'est considéré comme "mainstream" ou "exotique")

6) Des conventions pour des static const data members pour éviter de les mélanger avec les autres variables membres ou les paramètres template ?

Merci beaucoup
P.S. : j'ai déjà vu les naming convention de google et si je pose la question c'est que je veux essayer d'avoir un échantillon plus grand

[ternel]

1) Les abréviations dans les noms qui doivent être normalement en majuscules : MyCRTPClass ou MyCrtpClass ?

Aucune idée pour le C++. En java, on recommande MyCrtpClass.

2) Les paramètre template : plutôt template<class TYPE1, class TYPE2> ou template<class Type1, class Type2> ? Et si le premier cas n'est jamais utilisé (c'est celui que j'utilisais jusqu'à présent en fait), y-a-t-il une convention qui permet de différence un paramètre template d'un nom de classe ?

Je ne sais pas, mais j'utilise plutot le deuxieme des que le nom est un peu long

3) Les typedef de paramètres template (pour une classe de Traits par exemple) les typedef en général : une suggestion de notation "relativement" utilisée ?

en général, _t ou _type, les deux sont présents dans la lib standard.

5) Pour les variables membres : _myDataMember vs myDataMember_ vs myDataMember vs mMyDataMember vs m_myDataMember ?

Le '_' est mieux après qu'avant. Par contre il n'est pas utile d'utiliser à la fois le '_' et le "my", puisque les deux servent à indiquer la propriété.
J'ai personnellement une préférence pour member, et getMember(), setMember(), plutot que myMember, member(), member(...)

[Invité]

Le '_' est mieux après qu'avant.

en france, tout comme en angleterre, on lit de gauche a droite!
et non c'est pas exotique.

On retrouve egalement m_blabla

[3DArchi]

Salut,

en france, tout comme en angleterre, on lit de gauche a droite!
et non c'est pas exotique.

Quels sont les identificateurs interdits par la norme ?
Donc autant éviter tout les identifiants commençant par un '_'.

@Kaluza : De l'importance d'être constant : ce qui facilitera la lisibilité de ton code c'est d'être constant sur tes règles de nommage. (1)
Le seul point assez régulier est l'utilisation du tout MAJUSCULE plutôt pour les constantes (static const, enum).
Pour d'autres cas (membres, paramètres, variables locales, noms de classes, etc...), les projets que j'ai vu avait une grande variabilité sur les règles de nommage.



(1)=> Ce qui améliorera sans conteste la lisibilité de ton code c'est de correctement nommer tes items. Un 'Manager' même avec de bonnes règles de nommage bien respectées sera toujours ambigüe quand à son rôle.

[Invité]

Donc autant éviter tout les identifiants commençant par un '_'.

pourquoi "donc". C'est dangereux?
(je parle pour membre de classe)

[Aleph69]

Salut,

pour avoir un exemple concret, tu peux regarder dans des livres ou tu peux aussi ouvrir les fichiers de ta STL ou de bibliothèques (boost, ...). Cela pourra te donner quelques bonnes idées. N'oublie pas que tu peux également jouer avec la coloration syntaxique dans ton éditeur de texte.

Je réponds à tes questions au cas où c'est utile (ça te fera un sondage ;-)) :

1) j'aurais tendance à choisir MyCrtpClass pour que la majuscule ne serve qu'à séparer les mots. Cela permet de conserver une cohérence dans le code, de rester bien consistant avec tes choix de notations.

2) la première convention est par exemple utilisée dans l'implémentation de la STL de Visual. La seconde est sûrement également très utilisée. Pour les templates, on trouve de tout! Il y a aussi la notation hongroise tType1, tType2, tParameter, etc.

3) personnellement, j'utilise la même convention que pour le nommage de fonction. Je trouve cela plus esthétique à l'utilisation mais c'est vraiment une question de goût.

4) je mets un '_' à la fin. Remarque que, sans convention particulière, tu peux tout aussi bien mettre this-> devant chaque membre, c'est très explicite.

[Jean-Marc.Bourguet]

tu peux aussi ouvrir les fichiers de ta STL

Très mauvaise idée. Les implémentations de la SL sont bourées d'identificateurs réservés, pour éviter justement les interférences entre ton code et la SL. (Eh, les implémenteurs parlent même de "code obfuscated", on ne peut pas dire qu'ils considèrent ce style comme bon; juste comme nécessaire).

@galerien69, tu peux être un peu plus fin dans ce que tu retiens, la question est "est-ce que ça en vaut la peine?"

[Aleph69]

Bonjour Jean-Marc,

désolé, je ne vois pas de quoi tu parles. Peux-tu préciser ce que tu désignes par identificateurs réservés ou fournir un lien?

[JolyLoic]

Comme tout le monde dit, c'est question de préférence...
Voici les miennes :

1/ J'oscille, ça dépend des cas. En particulier, j'aurais tendance à mettre des minuscules pour un acronyme "universellement reconnu", et à garder les majuscules (ou le nom complet) pour un acronyme lié au projet.

2/ Type1

3/ Les typedef : Comme ce à quoi ils font référence.

4/ localVariable (j'ai enlevé le my, qui pour moi a une signification précise, voir point suivant)

5/ myDataMember (à noter que le 'my' est une décoration que je réserve exclusivement aux variables membres). Je préfère l'utilisation de my aux alternatives à base de _ ou de lettres isolées, en particulier parce que quand on discute du code à voix haute avec un collègue, ça hache moins la conversation. Et 'our' pour les variables membre statiques.

6/ Tout ce qui est constant à la compilation, MAJUSCULES.

[Jean-Marc.Bourguet]

désolé, je ne vois pas de quoi tu parles. Peux-tu préciser ce que tu désignes par identificateurs réservés ou fournir un lien?

Ceux que la FAQ appellent interdits. (Il en manque en passant, il y a toute une série d'identificateurs qui sont réservés dès qu'on inclus certains fichiers; en particulier tout ceux qui commencent par E+majuscule quand on inclus <errno.h>).

1) Les abréviations dans les noms qui doivent être normalement en majuscules : MyCRTPClass ou MyCrtpClass ?

Ma préférence va aux majuscules, mais les deux se rencontrent.

2) Les paramètre template : plutôt template<class TYPE1, class TYPE2> ou template<class Type1, class Type2> ? Et si le premier cas n'est jamais utilisé (c'est celui que j'utilisais jusqu'à présent en fait),

Deuxième cas.

y-a-t-il une convention qui permet de différence un paramètre template d'un nom de classe ?

Quel est l'intérêt?

3) Les typedef de paramètres template (pour une classe de Traits par exemple) les typedef en général : une suggestion de notation "relativement" utilisée ?

Même convention que n'importe quel type.

4) Les variables locales : my_local_variable ou myLocalVariable ou encore autre chose ? (j'ai l'impression que le premier est de moins en moins utilisé, mais c'est peut être qu'une impression).

Choix arbitraire. La mode à l'air au CamelCase... Quant au my pour les variables locales... ce sont les plus utilisées et à la portée la moins grande, donc moins décorée.

5) Pour les variables membres : _myDataMember vs myDataMember_ vs myDataMember vs mMyDataMember vs m_myDataMember ? (le cas 1 est différent des notations compilos car c'est une minuscule qui suit le "_" : personnellement c'est celle que j'utilise mais je ne sais pas si c'est considéré comme "mainstream" ou "exotique")

Je n'ai jamais vu C ceux qui double le my. Choix arbitraire parmis les autres. J'ai déjà vu _ en suffixe.

6) Des conventions pour des static const data members pour éviter de les mélanger avec les autres variables membres ou les paramètres template ?

J'utilise our (à la place de my) pour les membres données statiques. Mais pas pour les const, en particulier quand ils sont publics.

6/ Tout ce qui est constant à la compilation, MAJUSCULES.

Je réserve les MAJUSCULES au préprocesseur (à par T, U, V que j'utilise comme paramètres template quand il n'y a pas de bon nom). Ces identificateurs ne respectent pas les règles de portées, je les sépare clairement des autres pour éviter les conflits.

J'emploie parfois un p comme préfixe pour les paramètres quand le bon nom serait ambigu. Le cas le plus courant est dans les constructeurs pour des classes dont tous les membres données sont publiques et dont certains sont initialisés directement par un des paramètres du constructeurs. Un autre cas est quand je veux utiliser le résultat d'une conversion (le paramètre est un int, mon implémentation commence par le convertir en double et utilise ensuite le double -- la déclaration utilisera le nom sans p, la définition avec) P.E. un constructeur pour pair serait

Code :

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

1
2
3
4
template <typename T, typename U>
pair<T, U>::pair(T pFirst, U pSecond)
   : first(pFirst), second(pSecond)
{}

[JolyLoic]

Je réserve les MAJUSCULES au préprocesseur (à par T, U, V que j'utilise comme paramètres template quand il n'y a pas de bon nom). Ces identificateurs ne respectent pas les règles de portées, je les sépare clairement des autres pour éviter les conflits.

C'est ce que je faisais au début, mais après avoir refactoré pas mal de code utilisant un #define PI 3.14 en double const Pi=3.14;, je me suis dit que je n'avais pas particulièrement envie de renommer le code client (auquel je n'avais pas forcément accès) lors de ce genre de manips, et donc que je mettais aussi les constantes en MAJUSCULES. Mais je comprends ton point de vue de vouloir signaler ce qui ne respecte pas le scope.

J'emploie parfois un p comme préfixe pour les paramètres quand le bon nom serait ambigu. Le cas le plus courant est dans les constructeurs pour des classes dont tous les membres données sont publiques et dont certains sont initialisés directement par un des paramètres du constructeurs. Un autre cas est quand je veux utiliser le résultat d'une conversion (le paramètre est un int, mon implémentation commence par le convertir en double et utilise ensuite le double -- la déclaration utilisera le nom sans p, la définition avec) P.E. un constructeur pour pair serait

Code :

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

1
2
3
4
template <typename T, typename U>
pair<T, U>::pair(T pFirst, U pSecond)
   : first(pFirst), second(pSecond)
{}

Je vois de plus en plus pour ce genre de code :

Code :

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

1
2
3
4
template <typename T, typename U>
pair<T, U>::pair(T first, U second)
   : first(first), second(second)
{}

Je n'ai pas encore réussi à me faire une religion si ça me plait ou pas.

[Jean-Marc.Bourguet]

C'est ce que je faisais au début, mais après avoir refactoré pas mal de code utilisant un #define PI 3.14 en double const Pi=3.14;, je me suis dit que je n'avais pas particulièrement envie de renommer le code client (auquel je n'avais pas forcément accès) lors de ce genre de manips, et donc que je mettais aussi les constantes en MAJUSCULES. Mais je comprends ton point de vue de vouloir signaler ce qui ne respecte pas le scope.

Je fais

Code :

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

1
2
3
 
double const Pi = 3.141592653...;
#define PI Pi

J'ai vu trop d'endroits où il y avait des #ifdef PI quelque part.

Je vois de plus en plus pour ce genre de code :

Code :

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

1
2
3
4
template <typename T, typename U>
pair<T, U>::pair(T first, U second)
   : first(first), second(second)
{}

Je n'ai pas encore réussi à me faire une religion si ça me plait ou pas.

J'accepte, mais je n'écris plus.

[Invité]

@galerien69, tu peux être un peu plus fin dans ce que tu retiens, la question est "est-ce que ça en vaut la peine?"

Le but de ma remarque n'est pas de dire que le _ est possible en préfixe. 3DArchi le sait, c'est également précisé dans la FAQ et dans la norme, etc...

Le but est double:
- J'aime pas les déductions gratuites. Le donc me parait gratuit, je le fais remarquer
- reliée à la première, c'est simplement la question simple du : en quoi mettre un _ devant c'est mal.
Typographiquement marquant, on est pas censé voir des underscores partout dans le code, donc quand on en trouve ya de bonne chance que ca soit un membre.
my c'est deux lettres; et même si on fait du camelcase, ca me choque un peu de lire my. A la rigueur m ou m_.
Donc est-ce que ca en vaut le coup oui, c'est quoi le compromis, un peu de confort contre le risque d'écrire __maj? C'est comme interdire d'écrire int cinq=11/2.

[3DArchi]

- J'aime pas les déductions gratuites. Le donc me parait gratuit, je le fais remarquer

La norme réserve explicitement certaines constructions d'identificateurs. DONC autant ne pas utiliser les même constructions pour diminuer le risque de collision. Le donc n'était absolument pas gratuit mais visait bien à montrer une relation déductive dans le propos.

- reliée à la première, c'est simplement la question simple du : en quoi mettre un _ devant c'est mal.

C'est prendre un risque de collision avec un nom réservé par une implémentation. Donc produire un code qui ne compile pas avec certains compilateurs/STL ou, pire, dont le code produit n'est pas celui escompté.

Donc est-ce que ca en vaut le coup oui, c'est quoi le compromis, un peu de confort contre le risque d'écrire __maj?

Ce n'est pas le seul cas. Je reprends donc la question de Jean-Marc : Est ce que ça vaut le coût de retenir tous les cas ? (et j'ajoute : si tu es sûr de connaître tous les cas, crois tu qu'il en est de même dans ton équipe ?).

C'est comme interdire d'écrire int cinq=11/2.

....

[germinolegrand]

Voici ce que j'utilise :
1) MyCrtpClass (sauf si abreviation de mon invention)
2) template <class Type1, bool value> parce que le but est justement de pouvoir coder sans faire la différence entre ce qui est template ou non
3) la nomenclature du type sous-jacent
4) localVariable
5) m_membreVariable parce mon EDI est réglé pour l'auto-completion à 2 caractères et que j'ai pris cette habitude
6) staticConst (comme les locales) parce que MaClasse::variable est suffisant pour montrer le static.
Je réserve les MAJUSCULES exclusivement au preprocesseur.

[Invité]

La norme réserve explicitement certaines constructions d'identificateurs. DONC autant ne pas utiliser les même constructions pour diminuer le risque de collision. Le donc n'était absolument pas gratuit mais visait bien à montrer une relation déductive dans le propos.

Ben j'insiste encore. Le DONC fut-il en masjuscule est hatif (gratuit était vraisemblablement choquant...).
Ces certaines constructions n'incluent pas le _minuscule en tant que membre de classe.
Il n'y a pas risque de collision.

C'est prendre un risque de collision avec un nom réservé par une implémentation. Donc produire un code qui ne compile pas avec certains compilateurs/STL ou, pire, dont le code produit n'est pas celui escompté.

Le risque c'est donc que le compilateur ne respecte pas la norme...

(et j'ajoute : si tu es sûr de connaître tous les cas, crois tu qu'il en est de même dans ton équipe ?).

Je plains l'équipe qui développe dans le namespace global.

Sinon, on utilise cette convention au taff. Il parait même que c'est dans tout le département, et bon, ca a l'air d'aller. Depuis pas longtemps. Juste 3 ans.