Hello,
Depuis peu je teste une nouvelle convention pour le nommage de mes fonctions/variables de mes classes.
Avant de dire ce qui me motive à l'utiliser, je voudrais votre avis, et voir si l'un de vous devine pourquoi je fais ainsi, ou si tout le monde trouve ça illogique.
C'est par rapport à la visibilité des membres :

mouais. c'est comme les _ devant les fonction privée. je trouve ça pas terrible. mieux vaut encore utiliser la notation hongroise...
 

Est-ce vraiment utile de souligner la différence entre les membres plublics et privés ? Ceux qui sont privés ont une telement courte portée dans ton code...

A un détail près : c'est pas '_' mais 'z'. Vois-tu pourquoi ou cela te sembles stupide ?

Je suis d'accord. Jusqu'à peu je ne le faisais pas. Mais là je teste cete notation, et pour une certaine raison je le trouve très agréable d'utilisation, et la distinction très utile.

C'est pour qu'elles soient toujours à la fin de la liste des methodes ? t'as qu'à utiliser un vrai IDE qui ne te propose que les méthodes que tu peux appeler en fonction du contexte.

Voilà c'est ça.
Le probleme des '_' c'est qu'ils apparaissent en haut de la liste. Particulièrement chiant avec la STL sous VC++.
Je me suis dit pourquoi ne pas les mettre en fin de liste en les préfixant par 'z' (comme c'est privé/protected, on n'est rarement censé y faire appel, donc autant les faire dégager de la liste d'appel).
R3g : tu utilises quel IDE ?

heuu eclipse, mais je fais pas de C++ en fait.

Pourrir son code juste pour faire plaisir a certains IDE... tres peu pour moi. Mais il y a peu etre d'autres raisons?

faire fuire Taz ? (comment je parle de lui à la 3ème personne)

Taz >> skyzo va

C'est pas vraiment ça. C'est plutot utiliser 'z' au lieu de '_' ou 'm_'.

Beuark...

Doit bien y avoir des recommandations tout de même, non ?

D'après mon expérience, mes recommendations personnelles sont :  
 - séparer les membres privés des autres variables, via _ ou autre,
 - choisir des noms courts, mais pas cryptiques.
 
L'intérêt des noms courts est qu'ils sont faciles à mémoriser, ce qui facilite la compréhension et l'utilisation. Par court, j'entends typiquement entre 3 et 8 lettres. C'est facile en anglais, plus difficile en français mais bien souvent possible, avec les namespaces et les noms de classes devant. L'usage de noms longs doit rester limité et faie réfléchir à l'intérêt de la méthode.  Enfin, j'appelle mes variables de boucle avec i, j , k, l, etc, et pour mes itérateurs, it, jt, kt.

Pour moi un nom court fait tout sauf faciliter la compréhension.
Mes noms font très souvent plus de 10 lettres, et sont pratiquement toujours accompagnés d'un commentaire près de leur déclaration (sauf quand c'est trivial genre NumberOfElements).
Sur le projet actuel, j'ai un nom de classe qui fait 30 lettres. C'est un peu extrême, j'ai hésité à l'adopter, mais c'est pas plus mal : j'ai pas besoin de trimballer des commentaires à chaque fois pour rappeller à quoi ça correspond. C'est un cas isolé je vous rassure.

 
NumberOfElements => NbElements    
 
Nom de classe de 30 lettres   Alors tu fais :
   

Les noms longs, j'en ai vu pas mal, et à mon avis, ça ne facilite pas spécialement la compréhension. La concision n'a jamais été au détriment de la compréhension si les noms sont bien choisis et non cryptiques. Je n'accepte pas les acronymes par exemple.
Les noms très longs sont parfoie dûs à une mauvaise conception.
Un exemple simple (mais tiré d'un code réel), une librairie qui avait une classe utilitaire pour les conversions de types. Chaque méthode s'appelait "convertis_machin_en_truc", "convertis_bidule_en_truc" alors qu'il suffisait de définir "en_truc" et de surcharger cette méthode pour les types machin et bidule.
 
De façon générale, je réserve les noms longs aux variables globales et à celles qui sont peu utilisées.
Plus une variable est locale et/ou courament utilisée, plus son nom devrait être court.

Pour NbElements, je préfère aussi. Mais je l'utilise pas non plus. Je me débrouille pour avoir un type conteneur et j'utilise une méthode...Count() qui m'en renvoie le nombre.
Pour machinChoseTrucBiduleChouettes, ben oui (pas de new cependant). Au début ça m'a choqué, j'ai essayé un autre nom, j'ai demandé l'avis de personnes compétentes, et... on l'a gardé. Quand c'est un terme informatique c'est facile de condenser, un programmeur de base comprend. Mais là c'est un terme scientifique, et je me suis mis à la place de mio même en train d'essayer de piger le code avec un autre nom que celui-là. Ben même avec celui-là faut aller voir un spécialiste pour lui demander c'est quoi, etc... Si en plus il connait pas le nom, il est mal barré. Je te donne 2 versions condensées possibles de cette classe, dis mio celle que tu préfères et essaye de deviner ce qu'elle fait :
l'extrême :

l'intermédiaire, avec laquelle j'ai hésité

Je suis parfaitement d'accord.
N'empêche que souvent un nom de 10 lettres est plus parlant sans alourdir pour autant. GTK utilise des noms longs aussi, et tu peux comprendre un code sans jamais y avoir touché.

 
Si ça se trouve, le 'z' c'était pour te rendre hommage

Des noms de méthodes commençant par une majuscule : beurk !.
 
Personnellement je ne distingue pas les méthodes privée des publiques avec des prefixes et encore moins les membres car ils sont tous privés.
Si tu as fait un bon découpage logique de tes classes tu ne dois pas avoir beaucoup de méthodes et de membres, par exemple une dizaine de chaque max.
 
Le truc du 'z' alors ca achève tout, c immonde.

Question de goûts. Moi je déteste la première lettre en minuscule. POur mes classes héritant de Qt je le fais malgré tout, car c'est la convention. Sinon c'est NotationDromadaire.
 

Rien à voir. Quand t'as besoin de méthodes et de membres, il faut les mettre. Pour faire ce que tu dis il faut alors splitter une classe en plusieurs classes pour ne pas vaoir trop de méthodes => mauvais découpage logique. La dizaine de membres je suis plutot d'accord (y'a tjrs des exceptions), mais pour les méthodes, pas de limite. Moi je maintiens une taille maximale pour le code de mes fonctions (1 à 2 écrans) et dès que je dépasse ou qu'il commence à y avoir de grosses boucles imbriquées hop je me crée une fonction protected/private et j'y met le code.  
 

Pas sûr que ce soit pire que '_' qui pollue la liste des méthodes dispos affichées par l'IDE (en particulier avec la STL). Quand j'ai une classe qui hérite d'une autre genre QWidget et ses centaines de membres/fonctions, je suis content de retrouver tous mes petits en appuyant seulement sur z.