Existe-t-il une convention de capitalisation commune en C ++? [fermé]

Je fais beaucoup de travail en Python et Java, et ces deux langages ont des conventions assez communes (mais pas universelles) sur la façon dont la capitalisation doit être utilisée dans les identificateurs: à la fois utiliser PascalCasepour les noms de classe et ALL_CAPSpour les constantes "globales", mais pour d'autres identifiants un beaucoup de code Java utilise mixedCasealors que beaucoup de code Python utilise underscore_delimiters. Je sais qu'aucun langage ou bibliothèque n'impose une majuscule particulière, mais j'ai constaté que lorsque je m'en tiens aux conventions standard pour la langue que j'utilise, mon code semble beaucoup plus lisible.

Maintenant, je démarre un projet en C ++, et j'aimerais appliquer la même idée. Y a-t-il une convention de capitalisation la plus courante que je devrais connaître?

Y a-t-il une convention de capitalisation la plus courante que je devrais connaître?

C ++ est basé sur C, qui est assez vieux pour avoir développé tout un tas de conventions de nommage au moment où C ++ a été inventé. Ensuite, C ++ en a ajouté quelques-uns, et C n'a pas hésité à en penser de nouveaux non plus. Ajoutez à cela les nombreux langages dérivés du C, qui ont développé les conventions de nommage C de leur inventeur, au point où ils se sont fertilisés en retour sur C et C ++ ... En d'autres termes: C ++ n'en a pas, mais beaucoup de ces conventions.

Cependant, si vous recherchez la seule convention de dénomination, vous pouvez aussi bien regarder la convention de dénomination de la bibliothèque standard , car c'est la seule que tous les développeurs C ++ devront connaître et être habitués.

Quoi que vous utilisiez, la règle la plus importante est: soyez cohérent!

Fait intéressant, alors que j'ai commencé avec un mélange de PascalCase et camelCase, et que j'ai été impliqué dans de nombreux projets avec des conventions de nommage encore plus nombreuses, au fil des ans, je me suis retrouvé de plus en plus coincé avec la convention_library_convention. Ne me demandez pas pourquoi.

Convenons d'abord que ALL UPPERCASE est une horreur et doit être minimisé.

En C et C ++, il est donc utilisé comme convention pour les macros, et les macros uniquement, car les macros sont tout aussi laides, pour ne pas dire mal.

Les premiers C n'avaient pas const, donc les constantes devaient être exprimées sous forme de macros. De plus, à ces débuts, les programmes étaient beaucoup plus courts, de sorte que les pratiques qui étaient mauvaises aujourd'hui pouvaient être utilisées (par exemple, l'IIRC Brian Kernighan a écrit du code avec beaucoup de macros non majuscules). Et aussi, à cette époque, les claviers qui n'avaient pas de lettres minuscules existaient; J'en ai utilisé un, sur l'ordinateur norvégien Tandberg EC-10, vers 1980 ou 1979, je crois.

Ainsi, Java a repris la convention en majuscules pour les constantes du début C. Pendant ce temps, et peut-être même avant (je ne suis pas sûr de la chronologie ici), C a obtenu des constantes. Cependant, bien que certains / nombreux programmeurs C étaient coincés dans la convention précédente par nécessité de constantes comme macros majuscules, les programmeurs C ++ étaient plus sensés.

Le gros problème de nos jours est que les gens apprennent d'abord Java ou C (avec les conventions du moyen âge), puis viennent en C ++, emportant avec eux cette fausse convention majuscule.

Donc,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Eh bien, vous auriez pu penser que j'ai mentionné des claviers en majuscules uniquement pour plaisanter. Oh non. Parce qu'il s'agit simplement de la limitation technologique la plus ancienne et la plus archaïque qui a conduit aux conventions de dénomination, ou du moins affecté à quel point elles semblent fausses / correctes. Ensuite, il y a eu le problème de la transmission série 7 bits, qui a provoqué des problèmes correspondants avec les codes de caractères (encodages de caractères de newspeak) utilisés, ce qui signifiait que vous deviez vous limiter aux lettres de l'alphabet anglais, de A à Z.

En fait, je recommande de continuer à le faire. Voilà où nous en sommes! Nous ne sommes pas allés plus loin.

À l'heure actuelle, à partir de 2011, le C ++ standard prend en charge Unicode général dans les noms (et il le fait depuis 1998), contrairement aux implémentations C ++ réelles. En particulier, le compilateur g ++ a un caractère national contesté. Elle découle de cette limitation technologique des âges sombres.

Donc,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Enfin, au sujet des caractères de soulignement par rapport aux lettres majuscules entrecoupées,

• Réservez un formulaire facilement reconnaissable pour les noms de type.
• Réservez ALL UPPERCASE pour les macros.
• Être cohérent.

Je pense que c'est vraiment, sauf pour les règles comme "généralement éviter le nom à une seule lettre sauf pour (boucle, paramètre de modèle, bla bla)" et "éviter d'utiliser l, facilement confondu avec 1" et "éviter les majuscules O, facilement confondu avec 0 ". Évitez également d'utiliser des noms réservés, comme commencer par un trait de soulignement suivi de majuscules, contenant deux traits de soulignement successifs, ou commencer par un trait de soulignement et se trouver dans l'espace de noms global.

Santé et hth

J'ai généralement tendance à m'en tenir à la convention que je vois le plus dans les bases de code existantes pour la langue. Dans le cas de C ++, je vois généralement camelCase. Dans le cas de Ruby ou PHP, je vois généralement stuff_like_this.

De manière réaliste, cependant, la chose la plus importante est que vous choisissez une convention de style qui n'est pas totalement folle (dOnT_dO_tHiS) et que vous soyez cohérent avec elle. Faites en sorte que le style ne change pas dans le code d'un projet particulier. Si vous travaillez sur un projet existant, vous voudrez choisir le style qui existe déjà.

Eh bien, il y a des systèmes hongrois qui sont vraiment communs même maintenant, mais je préfère me couper la gorge que de le recommander. Les applications en hongrois sont meilleures car ses marques annotatives sont vraiment indicatives de la sémantique, bien que je pense que c'est un peu trop vif des abréviations quand un mot court ferait l'affaire. (Pour utiliser l'exemple de cette page Wikipédia, pourquoi utiliser rwpour la ligne quand rowun seul caractère est-il plus long? Ce n'est pas comme s'il y avait une pénurie mondiale de voyelles.)

En réalité, la chose la plus importante est de suivre les conventions des personnes avec lesquelles vous travaillez . Vraiment. La plupart des conventions fonctionnent assez bien, surtout si elles sont utilisées de manière cohérente. L'incohérence est pire (encore plus que les systèmes hongrois, que je déteste). Et si vous êtes seul, utilisez ce que vous voulez.

D'après ce que j'ai vu, cela varie selon les projets.

Les traits de soulignement intégrés sont probablement plus traditionnels / plus couramment utilisés en C sur Unix. La bibliothèque standard suit également cela, donc elle devrait presque certainement être traitée comme la valeur par défaut, à utiliser à moins qu'il y ait suffisamment de code existant utilisant une autre convention pour forcer absolument à utiliser cette autre convention.

Windows (pour un exemple) utilise le cas de chameau pour la plupart de ses fonctions, donc pas mal de gens qui développent pour Windows font de même. Ceci est également assez fréquent chez les personnes qui sont vraiment plus habituées à d'autres langages et tentent de traiter le C ++ comme s'il ne s'agissait que d'une variante étrange d'autre chose.

J'ai utilisé à la fois la bibliothèque standard et le boost comme référence pour les conventions de nommage. Cependant, il y a un problème avec cette solution.

La bibliothèque standard utilise une convention de dénomination conçue pour tenter de réduire les collisions avec votre code. Une partie de la solution consiste à utiliser toutes les lettres minuscules. D'où l'utilisation de soulignements au lieu de camelCase.

Je trouve que camelCase est lisible. PascalCase est souvent utilisé pour les noms de classe car il représente l'équivalent d'un nom propre. Cependant, je briserai cette règle pour les foncteurs qui sont plus représentatifs d'un verbe.

J'essaie de ne pas utiliser de macros. Cependant, quand je le fais, les macros sont conçues pour ressembler à des fonctions quand elles le peuvent. J'utilise également des valeurs const ou des énumérations au lieu de constantes manifestes, ce qui évite davantage les majuscules. Je préfixe généralement ces symboles avec un «k» pour indiquer qu'ils sont constants.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

Cette référence décrit une convention de dénomination qui est assez similaire à celles que j'ai vues utilisées avec succès dans au moins trois entreprises pour lesquelles j'ai travaillé dans le passé.

Contrairement à une réponse antérieure, j'éviterais de suivre la convention de dénomination de la bibliothèque standard C ++ dans mon propre code, ne serait-ce que pour éviter les collisions de noms avec la bibliothèque standard.

Cette réponse SO précédente sur un sujet connexe peut également être intéressante: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier