Discussion :

[kobton]

Bonjour,

je débute le codage d'un gros projet en c++ et j'aimerais avoir vos avis quand au nommage de vos classe, variables et fonction. J'

[kobton]

euh zut, fausse manip....

J'ai décidé d'utiliser la notation hongroise pour le nommage des variables.

Je note mes classes de la manière suivante : Class CThread ou Class CClasse

J'aimerais pouvoir marquer l'appartenance d'un méthode à une classe. Par ailleurs je montrerais bien également qu'un objet est une instanciation de telle ou telle classe. Quelqu'un a t'il des idées?

[yan]

Salut
regarde ce thread
http://www.developpez.net/forums/sho...d.php?t=480142

[Luc Hermitte]

N'appelle pas tes objets toto ... mais donne leur des noms intelligents qui représentent ce qu'il font vraiment ?

Sinon, ce n'est pas ça la notation hongroise -- cf l'autre fil dont l'adresse a été donnée par Mongaulois.

[nikko34]

Tu peux t'inspirer de celles de Java pour les contraintes, qui sont simples.

Sinon Luc a raison, le mieux est d'avoir des noms clairs et intelligents. Mais ce concept n'est pas facile à formaliser dans une norme de codage.

Pour la notation hongroise ( la vraie ), je pense qu'il faut laisser le programmeur choisir les endroits où c'est vraiment nécessaire. C'est très fastidieux de la forcer à toutes les variables.

[zais_ethael]

Je te conseille vraiment de laisser tomber ces normes à base de préfixe "C" ou "T". Elles datent d'une époque bien sombre où on mélangeait allègrement le C et le C++. Aujourd'hui cela n'a plus lieux d'être, tous les types autre que ceux de base sont des classes point, pas la peine de le spécifier.

[Médinoc]

Encore que, j'ai tendance à utiliser T pour les templates, et c'est sans parler de classes particulières du genre les interfaces COM...

[nirgal76]

A mon taf, on a décidé de suivre ce qui est dit ici :
http://www.possibility.com/Cpp/CppCodingStandard.html

[zais_ethael]

Encore que, j'ai tendance à utiliser T pour les templates, et c'est sans parler de classes particulières du genre les interfaces COM...

Les interfaces COM et de manière générale tout ce qui constitue la programmation Windows entre dans ma définition d'une époque bien sombre où on mélangeait allègrement le C et le C++.

[corrector]

Sinon Luc a raison, le mieux est d'avoir des noms clairs et intelligents. Mais ce concept n'est pas facile à formaliser dans une norme de codage

L'important étant d'avoir des programmes compréhensibles, ou bien des normes de codage hyper-précises et très contraignantes (parce qu'un programmeur laissé libre d'agir va faire absolument n'importe quoi, évidemment)?

[vimes]

Selon moi, les conventions de nommages pour les classes dépendent de la structure du projet. Pour les variables et les noms de fonctions, il y a une paire de conventions que je trouve pratique et pas trop contraignantes :

1. Pour tous :
   à l'intérieur d'un nom, séparer les sous-éléments logiques par une majuscule.
   (e.g. interator iIterateurDeFonction)
2. variables locales :
   premierLettreDuType%NomRepresentatif(faut enlever les %):
   (e.g. int iIndex;)
   si c'est une classe :
   si c'est un objet on utilise o comme premierLettre du type
   (e.g. Class oClass;)
   si c'est un pointeur on utilise o comme premierLettre du type
   (e.g. Class * pClass;)
3. parametre fonction :
   pareil que variable locale mais on le précède d'un '_'
   (e.g. void f(int _iIndex))
4. membre classe
   pareil que le parametre de la fonction, mais on le précède d'un 'm'
   (e.g. int m_iIndex;)
5. membre statique
   pareil que le parametre de la fonction, mais on le précède d'un 'ms'
   (e.g. static int ms_iIndex;)
6. on distingue les fonctions statique des fonctions d'instance en mettant s devant leur nom
   static void sMyFonction();
   void MyFonction();

[Luc Hermitte]

2- La première lettre du nom du type, c'est un truc régulièrement critiqué car cela va mettre une grouille pas possible au fil des refactorings. De plus, si la variable est bien nommée, cela n'apporte pas grand chose.

Dans le genre, que veut dire le 'o' d'objet quand on passe d'un int à un unsigned int, à un CyclicCounter, ou une Temperature, ou une Vitesse ...
Utilisé pour les gens qui venaient du C il y a 15 ans je ne dis pas. Aujourd'hui, cela n'apporte plus rien.

Ou d'un pointeur à un scoped_ptr, à un auto_ptr, à un shared_ptr, ... (quoiqu'encore un commun 'p' désignerait une nature et non plus un type (comme dans langage "typé")).

Bref, on rejoint les discussions sur la notation hongroise déjà tenues ici et dans l'autre fil.

3- Tu es au courant que :
- http://cpp.developpez.com/faq/cpp/?p...eurs_interdits
- et qu'il y a plus de personnes qui ont l'étrange idée de préfixer par le tiret-bas pour les variables membres, que de personnes qui le font pour les paramètres
?

[nikko34]

L'important étant d'avoir des programmes compréhensibles, ou bien des normes de codage hyper-précises et très contraignantes (parce qu'un programmeur laissé libre d'agir va faire absolument n'importe quoi, évidemment)?

J'ai l'impression que les gens qui rédigent des normes de codages ont une maladie qui les pousse à vouloir tout réglementer et à en faire 10 pages.

Rester simple et logique, c'est le mieux. Il faut faire confiance au développeur, et ça j'en connais beaucoup qui ont du mal. On peut aussi dire ce qu'il ne faut pas faire.

Selon moi, les conventions de nommages pour les classes dépendent de la structure du projet. Pour les variables et les noms de fonctions, il y a une paire de conventions que je trouve pratique et pas trop contraignantes

J'utilise que le 4. C'est pratique pour les listes d'initialisation. J'ai jamais trouvé trop d'intérêt à réglementer le reste. ( tant que ça reste clair )

( et j'ai souvent débuggé du code que je n'avais pas fait, si tu trouves pas le type d'une variable en moins de 10 secondes c'est qu'il y a un gros problème. Là où c'est drôle c'est qu'une fois on m'a rétorqué: "-oui mais moi je regarde le code dans le bloc-note alors il faut que je sache quel est le type sans IDE." Eh bien même sans IDE c'est quand même assez simple. Ou alors on a un tas de variables globales et un code spaghetti immonde, mais là franchement c'est pas sur la notation qu'il y a un problème )

J'ai aucun problème à appeller mon iterator "ite" et pas oIteratorMonIterator si il n'y a pas d'ambiguité

[vimes]

2- La première lettre du nom du type, c'est un truc régulièrement critiqué car cela va mettre une grouille pas possible au fil des refactorings. De plus, si la variable est bien nommée, cela n'apporte pas grand chose.

En quoi est-ce que ça devient le foutoir au fil des refactoring ?
L'un dans l'autre, je trouve que ça reste pour distinguer les doubles, les int, les float et les string en utilisant des abréviations come i,f,str .. pour les types complexes c'est vrai que l'apport n'est pas évident.

(quoiqu'encore un commun 'p' désignerait une nature et non plus un type (comme dans langage "typé")).

L'utilisation du o et du p est plutot dans ce cadre là.

3- Tu es au courant que :
- http://cpp.developpez.com/faq/cpp/?p...eurs_interdits
- et qu'il y a plus de personnes qui ont l'étrange idée de préfixer par le tiret-bas pour les variables membres, que de personnes qui le font pour les paramètres
?

Ah ben là, non, je ne savais pas. Grosse découverte. Je connais une boite dans laquelle j'ai bossé et qui utilise ces standard qui doit avoir les oreilles qui sifflent

Bah, après tout il faut s'adapter à ce que le groupe fait autour et si on est un peu plus 'carré' ça ne fait pas trop de mal.

[Luc Hermitte]

En quoi est-ce que ça devient le foutoir au fil des refactoring ?
L'un dans l'autre, je trouve que ça reste pour distinguer les doubles, les int, les float et les string en utilisant des abréviations come i,f,str .. pour les types complexes c'est vrai que l'apport n'est pas évident.

Parce que l'int va devenir un CyclicCounter (=> s/_i/_o), le float une Vitesse, etc, etc.

Au lieu de te concentrer sur ce qui est vraiment important : la nature, tu te concentres sur ce qui peut évoluer : le type C++ (bref : ce que n'est pas la notation hongroise -- qui même dans ce qu'elle est vraiment, peut avoir ses limitations). (on a comme déjà eu cette conversation dans ce fil et l'autre donné en lien)

Après, il m'arrive de me servir du pré-fixage par le type : quand dans un même contexte je manipule une donnée sous N formes différentes, la date en secondes depuis 70, la date en chaine, la date en classe métier applicative, la date en oracle::occi::TimeStamp, etc... Là, il m'arrive de préfixer par e(poch), s(string), t(lk à nous), o(racle). Mais c'est rare sorti de ce contexte.