Pourquoi le style de codage STL/Boost C++ est-il si différent de celui des autres ?

Question

Je suis un programmeur C++ assez novice, mais d'après mon expérience limitée du langage, la plupart des directives stylistiques standard du C++ (par ex. Directives stylistiques de Google C++ ) vont à l'encontre de ce qui est mis en œuvre dans les bibliothèques stl et boost.

Par exemple, les noms de classe de la bibliothèque standard C++ et de Boost sont toujours en minuscules, les mots étant séparés par des traits de soulignement (ex. std::vector , boost::unordered_map , std::map::const_iterator ), alors que la plupart des guides de style que j'ai vus pour le C++ tendent vers un style CamelCase (par ex. TcpConnection o Int32 ).

Il en va de même pour les méthodes. La bibliothèque standard et Boost utilisent le même style pour les méthodes et les fonctions que pour les classes (par ex. std::map<>::get_equal("foo") ), alors que la plupart des guides de style préconisent la pascalCase ou la CamelCase.

Si l'on compare cela à un langage comme Ruby, où la plupart des utilisateurs adhèrent aux conventions utilisées dans les bibliothèques de base, il semble étrange qu'il y ait une telle différence entre les bibliothèques C++ standard et le code de tout le monde.

Quelqu'un sait-il pourquoi ?

EDIT : Pour clarifier, je parle simplement du style textuel superficiel (casse, utilisation de caractères de soulignement, etc.) plutôt que du style d'implémentation réel.

Answer 1

Les caractères de soulignement et les minuscules étaient le style préféré par Bjarne Stroustrup dans "The C++ Programming Language". Si je me souviens bien, il avait déclaré que le soulignement dans les noms était préférable car il était plus lisible pour une communauté internationale dont l'anglais n'est pas la langue principale. Je n'ai aucune idée si son opinion est vraie ou non, mais je suppose que c'est l'origine.

Voici un lien vers sa FAQ où il aborde ce sujet :

http://www.stroustrup.com/bs_faq2.html#Hungarian

Un extrait expliquant ce qui vous intéresse en particulier :

Je préfère utiliser des traits de soulignement pour séparer les mots dans un identifiant (par exemple, element_count) plutôt que des alternatives, telles que elementCount et ElementCount. N'utilisez jamais de noms avec une majuscule (par exemple, BEGIN_TRANSACTION) car cela est conventionnellement réservé aux macros. Même si vous n'utilisez pas de macros, quelqu'un pourrait en avoir parsemé vos fichiers d'en-tête. Utilisez une majuscule initiale pour les types (par exemple, Square et Graph). Le langage C++ et la bibliothèque standard n'utilisent pas de majuscules, c'est pourquoi on utilise int plutôt que Int et string plutôt que String. De cette façon, vous pouvez reconnaître les types standard.

Answer 2

Il y a une bonne raison à côté de celle de Bjarne Stroustrup. Lorsque vous utilisez des foncteurs, vous voulez qu'ils ressemblent à des fonctions.

Mais avec les guides de style CamelCase, vous distinguez les classes des méthodes et des fonctions en utilisant des majuscules sur le premier caractère du nom des classes et des minuscules sur le premier caractère d'une méthode.

Cela n'est pas conforme à la programmation de style algorithmique C++. Comme il n'y a aucune raison de distinguer un foncteur d'une fonction, il est préférable d'utiliser les styles de codage c++ et stl lorsque vous voulez utiliser des foncteurs (et c'est généralement le cas).

Answer 3

Les seules règles vraiment nécessaires sont celles qui visent à prévenir les problèmes connus :

• Utilisez ALL_CAPS (plus les caractères de soulignement et les chiffres) pour les noms de préprocesseurs, et seulement pour les noms de préprocesseurs. Il peut être difficile de rechercher les problèmes causés par des collisions entre un identifiant (supposé) non préprocesseur et un nom de préprocesseur, et encore plus difficile de les résoudre.
• Ne commencez jamais un identifiant par un trait de soulignement, et n'ayez pas de double trait de soulignement à l'intérieur d'un identifiant. Ces éléments sont réservés à l'implémentation.

Au-delà de cela, soyez cohérent et ne soyez pas trop pointilleux. Les normes de codage doivent tenir compte de la règle n°0, qui est "Ne vous inquiétez pas pour les petites choses". Beaucoup trop de normes de codage transpirent les petites choses.

En ce qui concerne la norme C++ de Google, ce n'est pas la meilleure. Il s'agit plutôt d'une norme C plus ou moins. Elle interdit le passage par référence non constante, par exemple.