Nommage: Pourquoi les constantes nommées devraient-elles être toutes majuscules en C++/Java?
Je sais que pour C++ et Java, il s'agit d'une convention de nommage bien établie, selon laquelle les constantes doivent être écrites en majuscules, avec des traits de soulignement pour séparer les mots. Comme ceci (exemple Java):
public final static Color BACKGROUND_COLOR = Color.WHITE;
public final static Color TEXT_COLOR = Color.BLACK;
Cette convention de dénomination est facile à comprendre et à suivre, mais je me demande pourquoi choisir cette convention de dénomination par rapport à la convention de dénomination normale pour les variables:
public final static Color backgroundColor = COLOR.WHITE;
public final static Color textColor = COLOR.BLACK;
Il semble n'y avoir aucun besoin de changer l'apparence des constantes. Si nous voulons leur attribuer une valeur, le compilateur empêchera cela de toute façon. En fait, cela crée des problèmes si, plus tard, la constante devient une variable appropriée (car les couleurs sont configurables, par exemple).
Alors, quelle est la raison ultime pour écrire des constantes nommées en majuscules? Raisons historiques?
Je pense que ce n’est pas un problème technique, mais plutôt psychologique. Les conventions de dénomination ne sont pas à traiter par le compilateur (les noms ne le dérangent pas vraiment par l'ordinateur), mais plutôt par le programmeur qui parcourt le code pour avoir le plus d'informations possible avec le moins d'effort possible.
L'utilisation d'une convention de dénomination différente indique clairement au lecteur que ce que vous lisez est quelque chose de FIXE au moment de la compilation et que vous n'avez pas besoin de suivre le code pour déterminer où et comment la valeur est arrivée là.
Si je sais que quelque chose est une constante, je peux y faire référence plusieurs fois et je sais que cela ne changera pas. En d'autres termes, je sais que:
Color black = Colors.BLACK;
foo(black);
foo(black);
est le même que:
foo(Colors.BLACK);
foo(Colors.BLACK);
Cela peut être utile de savoir parfois. Personnellement, je préfère la convention de nommage .NET, qui consiste à utiliser la casse Pascal pour les constantes (et les méthodes):
Foo(Colors.Black);
Foo(Colors.Black);
Je ne suis pas un grand fan des cas criards ... mais j'aime bien que les constantes soient des constantes.
J'imagine qu'au début, à l'époque C, les gens implémentaient des "constantes" de manière symbolique, en utilisant le pré-processeur:
typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff
De telles "constantes" ne sont que des littéraux raffinés, et en tant que telles, elles ne se comportent pas tout à fait comme des variables. Vous ne pouvez pas, par exemple, prendre l'adresse d'une telle "constante":
Color *p = &BACKGROUND_COLOR; // Breaks!
Pour cette raison, il est logique de les "distinguer", car ce ne sont pas simplement des "variables que vous ne pouvez pas modifier".
Je crois qu'en C++, il s'agit d'une convention héritée de l'utilisation du préprocesseur pour #define des valeurs constantes. À l'époque, cela avait été fait pour éviter que le préprocesseur ne piétine tout votre code source, car les conventions habituelles pour les noms de fonctions et de variables en C les associeraient à la casse ou à la casse.
D'un point de vue C++, je dirais que c'est une mauvaise idée de mettre vos constantes en majuscules. J'ai dû déboguer plus d'un problème de construction à cause de cela. N'oubliez pas que le préprocesseur C++ ne connaît rien des espaces de noms et de la portée de nommage et qu'il se fera un plaisir de substituer ce qu'il pense être approprié même s'il est plutôt inapproprié.
En C (et ensuite en C++), les symboles définis avec la directive preprocessor #define étaient écrits en majuscules pour indiquer aux développeurs que le code n'était pas ce qu'il semblait et qu'il ne devait pas être traité comme un symbole normal. Les constantes n'existaient pas initialement dans K & R C (bien que const ait été ramené de C++ plus tard), les développeurs ont donc utilisé #define, d'où les majuscules.
Pour une raison quelconque, cela a été tordu dans Java car "les constantes sont des majuscules", d’où la convention actuelle erronée (IMO).
Je pense que les constantes majuscules sont un mauvais héritage de C. La logique derrière est la même que lorsque vous utilisez des traits de soulignement comme préfixes pour les membres privés. C'est un élément technique qui est déjà exprimé par des mots clés Java tels que private ou, dans le cas de constantes, static final.
Voir aussi: http://weblogs.Java.net/blog/2006/09/28/case-against-uppercases
Avec les constantes majuscules, les formules longues sont beaucoup plus faciles à lire, vous n'avez pas à deviner quel élément peut varier et ce qui ne peut pas. Ce n’est bien sûr qu’une convention, mais une convention utile.
N'utilisez pas ALL_CAPS pour les constantes simplement parce que les constantes étaient auparavant des macros.
Cette citation de C++ Core Guidelines résume tout.
Vous avez probablement raison. Les ordinateurs et les compilateurs (en particulier) n'étaient pas aussi rapides qu'aujourd'hui.
Joel Spolsky a mentionné dans un de ses essais à quel point il était impressionné par le temps de compilation de la nouvelle version de Turbo Pascal.
Je me souviens quand la compilation d'un programme pas trop gros (10-20KLOC) avec des superpositions en Turbo Pascal 5.0 sur PC XT 10MHz prenait environ 20 minutes ...
Je suppose qu'attendre que la compilation détecte une erreur n'était pas acceptable.
Et une convention comme celle-ci permet d’éviter les erreurs et les pertes de temps lors d’une compilation interrompue.
C'est une solution de contournement pour que vos outils de développement ne puissent pas repérer les propriétés d'un identifiant de manière commode.
Un peu comme la notation hongroise.
Lorsque votre IDE s'améliore, vous n'aurez plus besoin de convention de dénomination, mais celle qui dicte qu'un nom est une information complète sur la signification d'un identifiant.
Même cela peut évoluer: pourquoi ne pas créer un système de programmation où vous créez simplement des identifiants et ajoutez-y des propriétés telles que "brève description", "type", ... Lorsque l'outil arrive, il peut le faire de manière pratique, m in. " Programmation intentionnelle " est un indice.
Fondamentalement, lorsque les gens étaient amoureux de C, et que C++ et Java étaient nouveaux ou non encore créés, ils utilisaient des majuscules pour les noms constants du préprocesseur, afin d'indiquer qu'ils n'étaient pas réellement des variables.
#define INT_CONST 4
#define STRING_CONST "Yello."
#define FLOAT_CONST 3.6122448
Considérant que c’était le seul véritable moyen de définir une constante vraie en C (il est toujours possible de changer les variables const si vous savez comment faire), les constantes de préprocesseur comme celle-ci étaient simplement considérées comme des constantes et, en tant que telles, la signification des noms en majuscules était décalée. des constantes du préprocesseur aux constantes simplement en général. Ceci a ensuite été reporté dans les langues suivantes, devenant la pratique standard "consts = majuscules".
Cependant, d'autres langues ont leur propre style préféré (par exemple, C # et .NET préfèrent PascalCase), il est donc généralement préférable d'utiliser le style préféré, le cas échéant.
Lors de la programmation, il est important de créer un code compréhensible par les humains. Avoir des conventions de nommage aide à faire cela. Cela est préférable lorsque vous examinez du code que vous n'avez pas écrit et améliore la facilité de maintenance du code, car il est facile de faire la distinction entre les constantes et les variables.
En réalité, la plupart des directives de nommage C++ (y compris ISO, Boost, Sutter & Stroustrup et Google) déconseillent fortement de nommer des constantes avec des majuscules. Cela s'explique par le fait que les macros utilisent également des majuscules et peuvent être disséminées dans des fichiers d'en-tête, ce qui peut créer des comportements étranges. De toute façon, les gens utilisent toujours des majuscules car ils tirent les leçons de l’ancien code C/K & R ou ancien code hérité. Toutefois, dans le nouveau code Modern C++, vous devez éviter d’utiliser des majuscules pour toutes les applications, sauf les macros.
Ma théorie des animaux de compagnie, qui explique pourquoi toutes les capitales existent, est que sur de très vieilles machines, le code était saisi directement dans le code machine à l'aide de pavés numériques. Lorsque la langue d'Assembly est arrivée sur les lieux, elle utilisait uniquement des majuscules, car le clavier à cette époque n'était pas normalisé et certains claviers étaient limités, par exemple, en utilisant les mêmes pavés numériques pour entrer les alphabets, comme dans les téléphones à fonctions. Cela a ensuite été reporté dans de nombreuses langues comme le BASIC, qui est tout en majuscule. Lorsque les terminaux réels sont devenus disponibles et que les claviers ont commencé à être normalisés, les utilisateurs ont commencé à utiliser des cas mixtes sans réservation et toutes les majuscules ont été réservées pour des événements rares tels que les constantes par rapport aux fonctions et aux variables.
La plupart des directives C++ s'accordent désormais sur l'utilisation de "k" comme préfixe de constante suivi de nom avec soulignement ou CamelCase. Personnellement, je préfère kCameCase car il permet facilement de distinguer les variables qui sont nommées avec under_scores.
const float kFixedRadius = 3.141;
Ceci est uniquement pour aider le programmeur à comprendre ce qu'il regarde d'un coup d'oeil. Il est utile de savoir qu'une constante est utilisée pour que la valeur ne change pas, peu importe comment vous vous y référez.
Il n'y a pas vraiment de raison en ce qui concerne le compilateur. Les conventions de nommage sont purement cela, des conventions, pas vraiment des restrictions techniques.