Convention de nommage C # pour les constantes?

420
private const int THE_ANSWER = 42;

ou

private const int theAnswer = 42;

Personnellement, je pense qu'avec les IDE modernes, nous devrions utiliser camelCase car ALL_CAPS a l'air étrange. Qu'est-ce que tu penses?

mmiika
la source
4
@mmiika: quel est le sens "le" dans cet exemple? Est-ce comme dans le "Guide de l'auto-stoppeur de la galaxie" ou est-ce un report d'une norme de codage C ++? (Par exemple, un ancien framework C ++ pour Macintosh, THINK C [et plus tard, Symantec C ++], utilisait le préfixe "its" pour les membres pointeurs / références et "the" pour les membres scalaires.)
Peter Mortensen
5
@Peter, puisque la valeur de la constante est 42, je crois fermement que c'est une référence au Guide de l'auto-stoppeur de la galaxie .
Albireo
@PeterMortensen C'est créatif! Mais des noms comme itsEmployee et itsCostumer sonnent comme s'ils pourraient être trompeurs.
Camilo Martin
4
MSDN: Conventions de capitalisation msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.90).aspx
Captain Sensible
Je préfère theAnswer. Auparavant, j'étais un fan de la notation hongroise, mais depuis que j'ai appris à ne pas l'utiliser, j'aime éviter strictement toute méta-indication dans la dénomination. Il en va de même pour les interfaces comme IInterface. Je préfère Interfacable. Mais lorsque je travaille en équipe, je dois respecter les règles :(
nawfal

Réponses:

485

La convention de dénomination et de capitalisation recommandée consiste à utiliser P ascal C asing pour les constantes (Microsoft a un outil nommé StyleCop qui documente toutes les conventions préférées et peut vérifier la conformité de votre source - même si elle est un peu trop anale pour les goûts de nombreuses personnes) . par exemple

private const int TheAnswer = 42;

La convention de capitalisation Pascal est également documentée dans les Framework Design Guidelines de Microsoft .

Greg Beech
la source
51
En fait, StyleCop n'est "pas un produit Microsoft", mais "un outil développé par un développeur très passionné chez Microsoft (le soir et le week-end)". (Voir blogs.msdn.com/sourceanalysis/archive/2008/07/20/… et blogs.msdn.com/bharry/archive/2008/07/19/… ) pour plus de détails.) Cela étant dit, la dénomination du framework Microsoft conventions utilisent boîtier Pascal pour les constantes, de sorte que l'outil est tout simplement l' application de la norme que Microsoft ne publie et cautionne.
bdukes
12
@bdukes - Je n'ai pas dit que c'était un produit Microsoft, mais il a beaucoup d'utilisation et de support dans toute l'organisation (en tant qu'ancien employé, je l'utilisais des années avant que quiconque en dehors de Microsoft ne mette la main dessus, donc Je connais bien son héritage).
Greg Beech
8
Je n'aime pas cela, car la première lettre est généralement utilisée pour indiquer si une variable est visible de l'extérieur ou non. Dans le code, TheAnswer ressemble à une propriété publique, pas un const privé pour moi. Je préfère en fait aller avec un préfixe comme constTheAnswer et ConstTheAnswer.
Efrain
52
J'irais avec la notation TheAnswer sauf lorsque la valeur est 42, auquel cas je resterais définitivement avec l'approche ALL_CAPS.
Benoittr
4
Un champ privé ne devrait-il pas être enfermé dans un chameau, événement s'il est constant?
Markus Meyer
70

Visuellement, Upper Case est la voie à suivre. C'est tellement reconnaissable de cette façon. Par souci d'unicité et ne laissant aucune chance de deviner, je vote pour UPPER_CASE!

const int THE_ANSWER = 42;

Remarque : Les majuscules seront utiles lorsque les constantes doivent être utilisées dans le même fichier en haut de la page et à des fins d'intellisense; cependant, s'ils devaient être déplacés vers une classe indépendante, l'utilisation de majuscules ne ferait pas beaucoup de différence, par exemple:

public static class Constant
{
    public static readonly int Cons1 = 1;
    public static readonly int coNs2 = 2;
    public static readonly int cOns3 = 3;
    public static readonly int CONS4 = 4;
}

// Call constants from anywhere
// Since the class has a unique and recognizable name, Upper Case might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }
utileBee
la source
5
Moi aussi, je préfère cela car le boîtier Pascal peut facilement être confondu avec une référence de propriété.
bc3tech
8
Indépendamment des recommandations ci-dessus, je préfère également UPPER_CASE pour les constantes, car cela les rend beaucoup plus faciles à identifier par rapport à tous les autres cas.
dub stylee
23
@usefulBee "SNAKE_CASE" est fortement déconseillé en C #; Cette réponse est fausse. Le cas correct pour consts en C # est "TitleCase".
BrainSlugs83
13
@ BrainSlugs83, je ne pense pas qu'il y ait bien ou mal ici; cela dépend de la préférence et de ce qui rend le code plus clair.
utileBee
2
@usefulBee D'accord. Mais il est quand même bon de marquer quelle est la manière consensuelle de l'écrire. J'ai fait beaucoup de code Ruby récemment, et je pense que le SCREAMING_SNAKE_CASE est logique: il est très évident que c'est quelque chose de spécial, et vous n'avez même pas besoin de survoler / Aller à la définition pour découvrir de quoi il s'agit. Vous le savez immédiatement.
Per Lundberg
69

En fait, c'est

private const int TheAnswer = 42;

Au moins si vous regardez la bibliothèque .NET, quelle IMO est le meilleur moyen de décider des conventions de dénomination - de sorte que votre code ne semble pas à sa place.

bh213
la source
23

J'utilise toujours les majuscules pour les valeurs const, mais c'est plus par habitude que pour une raison particulière.

Bien sûr, il est facile de voir immédiatement que quelque chose est un const. La question que je me pose est la suivante: avons-nous vraiment besoin de ces informations? Cela nous aide-t-il de quelque manière que ce soit à éviter les erreurs? Si j'attribue une valeur à la const, le compilateur me dira que j'ai fait quelque chose de stupide.

Ma conclusion: allez avec le boîtier de chameau. Peut-être que je changerai aussi mon style ;-)

Éditer:

Ce quelque chose qui sent le hongrois n'est pas vraiment un argument valable, OMI. La question devrait toujours être: est-ce que ça aide ou ça fait mal?

Il y a des cas où le hongrois aide. Pas beaucoup de nos jours, mais ils existent toujours.

Treb
la source
30
Le code est lu beaucoup plus souvent qu'il n'est écrit. Bien sûr, lorsque vous écrivez le code, le compilateur vous empêchera de l'attribuer à une constante. Mais qu'en est-il du gars qui doit maintenir votre code dans deux ans? C'est vraiment agréable de pouvoir reconnaître une constante immédiatement.
Greg Hewgill,
2
Les IDE d'aujourd'hui attrapent beaucoup de problèmes avant la compilation. Je ne pense pas que la reconnaissance de la constante par son nom soit importante, sinon ne devriez-vous pas également ajouter un nom spécial pour les variables en lecture seule?
mmiika
5
Si vous y réfléchissez, l'habbit en majuscules provient probablement de macros de préprocesseur plutôt que de constantes (je n'ai jamais utilisé de majuscules pour les vraies constantes). Dans ce contexte, il est logique de distinguer les macros du code réel car une macro peut en fait être une expression et non une valeur constante, son expansion peut provoquer des effets secondaires, etc. Vous devez donc savoir quand vous utilisez une macro et quand vous utilisez une const. Je suis personnellement heureux de voir l'arrière des macros de préprocesseur, elles avaient beaucoup de potentiel pour rendre le code difficile à lire.
Tim Long
7
@Tim: Je suis d'accord, au final, les macros de préprocesseur ont fait plus de mal que de bien. Ma macro PP préférée: "#DEFINE Private Public" ;-)
Treb
1
@Tim: la bibliothèque C ++ Standard Tempate a adopté des minuscules pour les constantes, par exemple std :: string :: npos ( cplusplus.com/reference/string/string/npos ). Donc ALL_CAPS est uniquement pour les macros et les directives de préprocesseur, ce qui le rend encore plus stupide en C #.
Richard Dingwall
16

Premièrement, la notation hongroise consiste à utiliser un préfixe pour afficher le type de données d'un paramètre ou l'utilisation prévue. Conventions de dénomination de Microsoft pour dire non à la notation hongroise http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

L'utilisation de UPPERCASE n'est pas encouragée comme indiqué ici: Pascal Case est la convention acceptable et SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft indique également ici que UPPERCASE peut être utilisé s'il est fait pour correspondre au schéma existant. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

Cela résume à peu près tout.

user31939
la source
3
Oui, la notation hongroise n'est pas tout en majuscules.
snibbets
13

Dans son article Constants (Guide de programmation C #) , Microsoft donne l'exemple suivant:

class Calendar3
{
    const int months = 12;
    const int weeks = 52;
    const int days = 365;

    const double daysPerWeek = (double) days / (double) weeks;
    const double daysPerMonth = (double) days / (double) months;
}

Ainsi, pour les constantes, il semble que Microsoft recommande l'utilisation de camelCasing. Mais notez que ces constantes sont définies localement .

On peut soutenir que la dénomination des constantes visibles de l'extérieur présente un plus grand intérêt. En pratique, Microsoft documente ses constantes publiques dans la bibliothèque de classes .NET sous forme de champs . Voici quelques exemples:

Les deux premiers en sont des exemples PascalCasing. Le troisième semble suivre les conventions de capitalisation de Microsoft pour un acronyme à deux lettres (bien que pi ne soit pas un acronyme). Et le quatrième semble suggérer que la règle pour un acryonyme à deux lettres s'étend à un acronyme ou identifiant à une seule lettre tel que E(qui représente la constante mathématique e ).

En outre, dans son document sur les conventions de capitalisation, Microsoft indique très directement que les identificateurs de champ doivent être nommés via PascalCasinget donne les exemples suivants pour MessageQueue.InfiniteTimeout et UInt32.Min :

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Conclusion: à utiliser PascalCasingpour les constantes publiques (qui sont documentées en tant que constou static readonlychamps).

Enfin, pour autant que je sache, Microsoft ne préconise pas de conventions de dénomination ou de capitalisation spécifiques pour les identificateurs privés, comme indiqué dans les exemples présentés dans la question.

DavidRR
la source
Le développeur qui a écrit cet article ne suivait clairement pas les conventions de style recommandées par Microsoft pour C #.
BrainSlugs83
2
L'article signalé par cette réponse a changé. Les consts sont maintenant publics et ont été PascalCased. Compte tenu de ces deux changements, cela ne permet pas de savoir si les constantes privées doivent être PascalCased ou camelCased.
Metalogic
12

Laissez le hongrois aux Hongrois.

Dans l'exemple, je laisserais même de côté l'article définitif et j'irais avec

private const int Answer = 42;

Est-ce la réponse ou est-ce la réponse?

* A fait éditer comme Pascal strictement correct, cependant je pensais que la question cherchait plus d'une réponse à la vie, l'univers et tout .

Colombe
la source
2
Dans ce cas précis, c'est la réponse. Mais seulement parce que j'aime tellement lire D.Adams.
Treb
oui, mais quelle est la question? et ne me nourris pas que désolé pour la gêne occasionnée;)
plongé
2
Ah, mais puisque vous connaissez déjà la réponse, vous ne pouvez pas connaître la question. Ils s'excluent mutuellement. (Je parie que vous le saviez déjà ;-)
Treb
C'est la bonne réponse à la question du PO. - Je vous voterais deux fois pour avoir supprimé le Thesi je le pouvais. :-)
BrainSlugs83
Qu'est-ce que quelqu'un est hongrois, cette réponse dit-elle qu'il est autorisé à utiliser l'autre convention?
Captain Prinny
6

En fait, j'ai tendance à préférer PascalCase ici - mais par habitude, je suis coupable de UPPER_CASE ...

Marc Gravell
la source
6

ALL_CAPS est tiré de la façon de travailler C et C ++ je crois. Cet article explique ici comment les différences de style sont apparues.

Dans les nouveaux IDE tels que Visual Studio, il est facile d'identifier les types, la portée et s'ils sont constants, ce n'est donc pas strictement nécessaire.

Les logiciels FxCop et Microsoft StyleCop vous aideront à vous guider et à vérifier votre code afin que tout le monde fonctionne de la même manière.

John
la source