On t'a dit des conneries Whiskey. Tu fais comme tu veux du moment que t'es constant et idéalement a un truc reproductible (via un fichier d'IDE, ou autre outil du genre clang format) ou à défaut une documentation. Si t'as un truc reproductible c'est bien car tu peux facilement inclure d'autres gens dans le projet et automatiser la mise en forme pour avoir un truc cohérent.
Perso je trouve camel case dégueulasse et illisible donc j'utilise toujours des underscores pour les noms de fonction et les variables, pour les classes je reste en camel case mais généralement tu ne vois quasiment plus apparaitre les types dans le code, dans tous les languages à la mode (c++, language sans vraiment de type comme python, etc.) sauf lorsque tu appelles le constructeur directement.
Par exemple cher google z'ont un document qui décrit leurs conventions et point barre, parfois c'est justifié, parfois c'est juste un choix arbitraire par soucis de lisibilité et de cohérence:
https://google.github.io/styleguide/cppguide.html
D'ailleurs la librairie standard en C++ c'est du snake case, pareil pour Boost, donc ça n'a rien de vieux, c'est utilisé tous les jours
Le seul argument à peu près """viable""" c'est que parfois des mecs disent vouloir se distinguer de la librairie sous jacente qu'ils utilisent (qui est souvent snake_case) et donc utilisent camel case partout. Mais c'est bidon c'est juste choix.
L'important c'est la reproductibilité (et un minimum de cohérence interne, accord avec les autres contributeurs du projet, etc.)
- - - Mise à jour - - -
D'ailleurs concernant le 1_000_000
en C++ on a officiellement depuis C++14:
Code:
auto le_million = 1'000'000;
Elle est pas belle la vie