Quelle est l'histoire derrière la convention de nommage des constantes en majuscules?

Mon intuition est que cela a commencé avec le préprocesseur C, où les gens ont développé une pratique pour nommer les macros de préprocesseur en majuscules afin qu'ils vivent efficacement dans un espace de noms séparé et évitent les collisions de noms. Ma conviction est que cette pratique a ensuite été mal comprise et bâtardée pour s'appliquer également aux constantes non préprocesseur ( enums, constvariables).

Nommer les macros du préprocesseur en majuscules me semble vraiment utile. Nommer les constantes générales de cette façon, pas tellement (et contre-productif si cela crée des collisions avec des noms de macro).

Suis-je hors de la base? La pratique de capitaliser les constantes est-elle antérieure à C?

Pour C, la première édition de The C Programming Language (alias K&R) suggère que votre intuition sur les macros de préprocesseur est correcte:

Les noms de constantes symboliques sont généralement écrits en majuscules afin de pouvoir les distinguer facilement des noms de variables en minuscules.

À bien des égards, il s'agissait d'un résidu du langage d'assemblage, où les macros étaient définies en majuscules avec des étiquettes, des opcodes, des noms de registre et tout le reste. L'avènement de l'assemblage de style AT & T a changé cela sur certaines plates-formes, mais je pense qu'il était fortement influencé par le fait que les terminaux prenant en charge les minuscules devenaient une chose et Unix était ce que j'appellerais un "système d'exploitation en minuscules".

Sur les deux autres points, vous frappez .500:

Enum

Au moment de la publication de la deuxième édition, enums avaient été définis, ils étaient appelés constantes d'énumération et couverts dans la section sur les constantes. Étant donné que les constantes définies par an enumsont représentées par des symboles, cela en fait des constantes symboliques qui, si vous suivez la convention recommandée, doivent être nommées en majuscules. (Comme les macros de préprocesseur, rien ne vous empêche de faire autrement.)

L'implication ici est que, contrairement à certains langages qui ont suivi, C ne traite pas enumcomme un type de première classe où les types eux-mêmes sont distincts, les valeurs d'énumération sont spécifiques à chaque type et peuvent être réutilisées dans d'autres. Au lieu de cela, il s'agit en fait d'un raccourci pratique #definequi produit des séquences d'entiers avec des identificateurs attachés. Cela fait

enum foo  { BAR, BAZ };
enum quux { BLETCH, BAZ };

invalide car tous les symboles partagent la portée et BAZsont redéfinis. (Il s'agissait d'une amélioration par rapport au préprocesseur qui, à l'époque, ne prévenait pas qu'un #defineclobbering autre.) En outre, C ne se soucie pas si vous les mélangez parce qu'ils ne sont que des entiers, ce qui rend

enum foo  { BAR, BAZ };
enum quux { BLETCH, BLRFL };

enum foo variable = BLETCH;

complètement valide même sur un compilateur moderne avec tous les avertissements activés.

Const

NB: Le constmot-clé est né en 1981 avec C With Classes de Stroustrup (qui a évolué en C ++) et a finalement été adopté par C. Le choix du nom est malheureux, car il entre en collision avec l'utilisation par K&R du terme constant pour signifier ce que nous appellerions maintenant un littéral (par exemple 38, 'x'ou "squabble"). Le texte de la deuxième édition n'a pas été réécrit pour refléter cela.

Les variables déclarées constsont une histoire différente car ce sont toujours des variables. Ils ne sont pas censés être modifiés, mais si la notion de variable constante a plus de sens que, disons, les crevettes géantes est un aliment pour une autre discussion. Quoi qu'il en soit, C n'a jamais été vraiment sérieux à ce sujet car la norme exige uniquement que le compilateur émette un diagnostic lorsque vous essayez d'en changer un. Le comportement réel n'est pas défini si une modification est compilée et exécutée.

Étant des variables, il est logique que tout constrespecte la convention d'être nommé en minuscules. Les utiliser pour représenter des littéraux présente certains avantages de sécurité de type mais ne permet pas une bonne optimisation si vous devez atteindre entre les unités de compilation pour obtenir la valeur.

Ce qu'ils ne sont pas, ce sont des constantes au sens K&R, et pour cette raison, leurs identifiants ne doivent pas être en majuscules. Certaines personnes les utilisent de cette façon, mais ce n'est pas une pratique que je recommande, sauf dans quelques cas spécifiques.