C convention de nommage des constantes?

private const int THE_ANSWER = 42;

ou

private const int theAnswer = 42;

personnellement, je pense qu'avec les IDEs modernes nous devrions aller avec camelCase comme ALL_CAPS semble étrange. Qu'en pensez-vous?

337
demandé sur AK47 2008-10-28 11:16:45

9 réponses

la Convention recommandée de nommage et de capitalisation est D'utiliser Pascal casing pour les constantes (Microsoft a un outil appelé StyleCop qui documente toutes les conventions préférées et peut vérifier votre source pour la conformité - bien qu'il soit un peu trop anally retentive pour les goûts de beaucoup de gens). par exemple

private const int TheAnswer = 42;

la convention de capitalisation Pascal est également documentée dans le cadre de Microsoft Lignes Directrices

400
répondu Greg Beech 2017-07-13 12:56:08

en fait, c'est

private const int TheAnswer = 42;

au moins si vous regardez la bibliothèque .NET, qui IMO est le meilleur moyen de décider des conventions de nommage - afin que votre code ne semble pas hors de propos.

61
répondu bh213 2008-10-28 08:23:12

visuellement, en majuscules est la voie à suivre. C'est tellement reconnaissable de cette façon. Pour le bien de l'unicité et ne laissant aucune chance de deviner, je vote pour UPPER_CASE!

const int THE_ANSWER = 42;

Note : le cas supérieur sera utile lorsque les constantes doivent être utilisées dans le même fichier en haut de la page et à des fins d'intellisense; toutefois, si elles devaient être déplacées dans une classe indépendante, l'utilisation du cas supérieur ne ferait pas beaucoup de différence, car un 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 might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }
44
répondu usefulBee 2017-05-15 20:06:19

j'y vais toujours avec la majuscule pour const valeurs, 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 cette information? Nous permet-elle d'une quelconque manière à é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 chameau. Peut-être que je vais changer mon style trop ;-)

Edit:

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

il y a des cas où la Hongrie aide. Pas beaucoup aujourd'hui, mais ils existent encore.

20
répondu Treb 2008-10-28 08:21:42

tout d'abord, la Notation hongroise est la pratique d'utiliser un préfixe pour afficher le type de données d'un paramètre ou son utilisation prévue. Conventions de nommage 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 majuscules N'est pas encouragée comme indiqué ici: Pascal Case est la convention acceptable et les casquettes hurlantes. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft indique également ici que le majuscule 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 assez bien.

14
répondu user31939 2008-10-28 10:37:47

laisser le Hongrois aux Hongrois.

dans l'exemple, j'omettrais même l'article définitif et je dirais simplement

private const int Answer = 42;

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

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

13
répondu dove 2010-02-03 11:19:37

dans son article constantes (C # Guide de programmation) , 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 apparaît que Microsoft recommande l'utilisation de camelCasing . Mais notez que ces constantes sont définies localement .

sans doute, le nom des constantes externes-visibles est de plus intérêt. En pratique, Microsoft documente son public constants dans la bibliothèque de classe .NET comme champs . Voici quelques exemples:

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

en outre, dans son document conventions de capitalisation, Microsoft indique très directement que les identificateurs de champ devraient être nommés via PascalCasing et 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 PascalCasing pour les constantes publiques (qui sont documentées sous les champs const ou static readonly ).

enfin, autant que je sache, Microsoft ne préconise pas de conventions spécifiques de nommage ou de capitalisation pour les identificateurs privés , comme le montrent les exemples présentés dans la question.

11
répondu DavidRR 2018-02-21 13:22:19

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

6
répondu Marc Gravell 2008-10-28 08:27:45

La ALL_CAPS est prise à partir du C et C++ façon de travailler, je crois. Cet article ici explique comment les différences de style ont vu le jour.

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

le FxCop et Microsoft StyleCop logiciel vous aidera à donner des directives et de vérifier votre code pour que tout le monde fonctionne de la même façon.

6
répondu John 2010-02-03 11:07:58