Discussion :

[three minute hero]

Good morning francophonie,

En observant le code d'un peu tout le monde, je remarque que tous ou presque utilisent la convention de nommage à la Pascal (ceGenreDeChoses, également utilisée en Java), alors que les racines du langage C++ et sa librairie standard elle-même indiquent (même si n'imposent pas) une convention de nommage à la C, que_vous_devez_connaître_également.
Pourquoi ne l'utilisez-vous pas ?

Évidemment, ce n'est qu'une question de style, rien de bien crucial. C'est juste intrigant.

[Spout]

Pour ma part, c'est totalement arbitraire. Je préfère simplement des variables/fonctions GetQuelqueChose que get_quelque_chose. Je trouve ça plus propre à relire et moins long.
Mais encore une fois, c'est totalement arbitraire .

[three minute hero]

Ce qui m'intrigue le plus, c'est le choix d'une autre convention de nommage que la librairie standard dudit langage.
Par exemple, j'aime bien la notation C, mais lorsque je code en Java, je me pose pas de question, jeCodeCommeÇa, pour faire corps avec la librairie standard.

Comme tout le monde se fait sa propre petite convention, on se retrouve fatalement avec des codes très hétérogènes du fait de l'utilisation de différentes lib dans un même projet.
J'ai très rarement vu de gens nommer à la C en Java, alors que l'inverse est beaucoup plus fréquent.

[3DArchi]

L'habitude . C'est une mauvaise raison mais c'en est une très courante.

[three minute hero]

Le plus troublant c'est le cas des développeurs de boost.
Ils ont fait le choix de nommer à la C pour faire corps avec la STL (et dans leur cas, faire corps, c'est peu dire). Et pourtant, quand on lit leurs docs, on retrouve des codes où ils nomment à la Pascal, comme si ça les soulageait de pouvoir ENFIN placer des majuscules, comme si en réalité ça les pesait de nommer à la C et que s'ils avaient vraiment eu le choix, ils auraient nommé à la Java.

Du coup, plus que des questions de goûts esthétiques ou d'habitude, j'ai l'impression que les gens trouvent des défauts à cette notation, que ça les gêne de ne pas pouvoir différencier le nom d'une classe d'un nom de fonction ou de variable (alors que le contexte laisse rapidement peu de doute à ce sujet).

[TheDrev]

Avant j'écrivais aussi en CamelCase, mais je suis tombé sur http://www.gnu.org/prep/standards/ht...mes.html#Names en recherchant de la doc sur g++. Je trouve que c'est effectivement plus simple a lire, que cela facilite la frappe a l'aveugle, si on y reflechit, il faut simplement appuyer sur _ au lieu de shift droit ou shifte gauche + la touche voulut...

[ac_wingless]

Les règles de codage datent en général de bien avant la STL (et oui, bien des chefs de projets sont des dinosaures! ).
Il y a aussi le fait que de nombreuses librairies utilisent CetteConvention, en particulier en environnement Windows.
Ceci dit, nous avons basculé sur une notation très proche de_celle_ci en 2006 pour tous les nouveaux codes, quel que soit le langage (y compris en électronique / électricité / conception), lors d'un changement d'assurance qualité. Il n'y a pas eu vraiment de résistance en interne, et la plupart de l'équipe apprécie maintenant le gain en lisibilité.
Ce qui nous a motivé, cependant, était purement lié à des critères de lisibilité, et pas à des questions de cohérence avec telle ou telle librairie de tel ou tel langage (bien que C++ soit très important chez nous, ce n'est pas le seul langage, et la STL est devenue tellement transparente qu'elle se fond pratiquement dans les mots-clés).

[three minute hero]

[HS]
J'ajouterais qu'avec une disposition de clavier évoluée comme celle-ci, l'underscore est accessible avec altgr-espace. Un pur régal geekesque
[/HS]

[TheDrev]

cela doit se configurer sur un clavier normale avec un fichier .map et un peu de typex

Sinon, il est certains que dans un projet, quel que soit la notation choisie, il faut essayer de rompre avec ses habitudes pour se fondre dans le code existant... rien n'est plus désagréable de coder avec 2 convention en meme temps !

[three minute hero]

une notation très proche de_celle_ci en 2006

Justement, quelles sont les différences de la variante utilisée par ton entreprise ?

[three minute hero]

Sinon, il est certains que dans un projet, quel que soit la notation choisie, il faut essayer de rompre avec ses habitudes pour se fondre dans le code existant... rien n'est plus désagréable de coder avec 2 convention en meme temps !

Justement ! Si c'est si désagréable, pourquoi tout le monde choisi une notation différente de la STL ? En effet, à partir de ça on code avec deux conventions différentes en même temps…

[Médinoc]

Pour moi: D'une part, pour m'en différentier (ainsi, je vois du premier coup d'oeil que la fonction que j'appelle n'est pas une fonction STL, mais une fonction de mon code ou de Windows), d'autre part, parce que je trouve le CamelCase plus lisible.

[mister3957]

Le principal est d'avoir un nommage uniforme dans l'enceinte de ton espace de nom, et nécessairement dans tous les projets de ton entreprise.

Se distinguer de "l'extérieur" au niveau du style permet d'avoir un certain "caractère" et biensûr de tout de suite voir si un code provient d'un de tes collègue ou d'un truc récupérer sur le net ou autre.

Et pour finir, travailler sur un projet C++ avec le style de la STL par exemple, puis on te fait passer sur Java où tu dois te réadapter au style Java... c'est pas terrible terrible.

[zais_ethael]

Raisons historiques tout simplement. Pour ce qui est du pourquoi de ces raisons historiques... je dirais que c'est le même problème partout.

Quel que soit la norme que tu choisis et ses sois-disant avantages (de toutes façon fort subjectifs dans ce cas précis), ceux-ci sont dérisoires par rapport à l'énorme atout d'avoir une seule norme universellement respectée.
Cela touche des domaines très variés en informatique, cela va du protocole IP au raccourci clavier pour faire un copier-coller, et normalement tout programmeur expérimenté en a plus ou moins conscience.

L'ennui c'est que ça c'est aujourd'hui. Il y a seulement 20 ans il y avait encore un grand nombre de nos collègues qui ne programmaient pas de façon OS-portable, ni même pour une famille d'OS, ni même pour les ordinateurs d'un constructeur précis, mais pour un modèle précis d'ordinateur. Il y a 20 ans, tout le monde n'utilisait pas forcément IP (un protocole unique pour les communications, à quoi ça sert? En quoi c'est un problème que chacun utilise le sien?). Alors oui, au vu de nos standards actuels, les informaticiens de l'époque étaient vraiment une bande de gros beaufs, mais bon faut faire avec.

[screetch]

je ne suis pas choqué car pour moi la lib standard se rapproche du langage lui meme, et les types sont donc en lowercase (int, float, vector, shared_ptr,etc)
ca differencie assez bien les choses qui nous appartiennent des choses deja ecrites, finalement.

[oodini]

[HS]
J'ajouterais qu'avec une disposition de clavier évoluée comme celle-ci, l'underscore est accessible avec alt-espace. Un pur régal geekesque
[/HS]

Sauf que sous Windows, ce raccourci clavier est déjà affecté.

[r0d]

En ce qui me concerne, je plussoie les raisons déjà citées,en particulier: différencier, justement, mon code de celui de la STL et de boost (et des autres libs: j'utilise beaucoup de libs C, contraintes de mon environnement professionnel).

A laquelle je rajouterais:
. j'utilise CetteNotation pour les fonctions et celleLa pour les variables. Ce qui me permet de différencier les deux, et c'est plus lourd à faire avec cette_notation.
. j'ai une sainte horreur des '_'. J'ai été traumatisé par les underscores quand j'étais jeune et que j'essayais de comprendre le code de la stl

[mister3957]

Après ça ne concerne pas que les noms de variables et les noms de fonctions.

Y'a les membres, les types de variables, les pointeurs/références, les membres statics, les foncteurs, les templates (surtout si tu fais de la méta programmation), les itérateurs etc...

[three minute hero]

@oodini:
Woops, il s'agit bien sûr d'altgr-espace, j'ai édité le message.

@tous:
Merci pour vos réponses, j'y vois un peu plus clair
Comme beaucoup, j'aime me rattacher à un standard une fois pour toute pour ne plus avoir à y réfléchir. Mais puisqu'il y a tant de bonnes raisons de se différencier de celui de la STL et que presque tout le monde est d'accord pour faire ainsi, je vais peut-être reconsidérer la question !

Cela dit, continuez à faire part de vos avis, je trouve cela très instructif.

[three minute hero]

Après avoir un peu réfléchi à tout ça, je reviens avec quelques objections :

Premièrement :
Dans certains cas d'utilisation de la STL et de Boost, on est forcé de ramener certains noms jusqu'à nos interfaces. Par exemple, si l'on veut faire ceci :

Code :

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

1
2
3
4
5
6
7
 
class SuperVector: private std::vector
{
    public:
        void shuffleContent();
        using std::vector::push_back;
};

on se retrouve avec une interface dont le nommage est hétérogène. Certes, l'exemple n'est pas très probant et c'est douteux sur le plan de la conception, mais il y a vraiment des cas où on ne peut y échapper. Par exemple dans Boost.Spirit, sans rentrer dans les détails, on est obligés d'implémenter une classe interne dont le nom est definition, et non Definition.


Deuxièmement :
J'ai bien aimé l'argument disant que la STL se fondait un peu dans les mot-clés du langage lui-même (int, double / vector, string). Cependant, il semblerait que les concepts que nous réservent C++0x aient adoptés un nommage CamelCase (tels que InputIterator, OutputIterator). On aura donc du CamelCase dans la STL. Comment différencier d'un coup d'œil un concept de la STL avec une classe maison si un using namespace std est présent ?
Par ailleurs, quelle convention pensez-vous adopter pour vos concepts ?