Conventions de dénomination pour les acronymes constants

Question

La convention de dénomination selon StyleCop pour les constantes est Pascal.

Par exemple

private const double InchToMm= 2.54; 

Qu'en convention de nommage pour l'acronyme?

private const int Dpi = 96; 

ou

private const int DPI = 96; 

Answer 1

Le Framework Design Guidelines de Microsoft dit:

La convention de PascalCasing, utilisé pour tous les identifiants, à l'exception des paramètres noms, capitalise le premier caractère de chaque mot (y compris acronymes sur deux lettres de longueur), comme le montre les exemples suivants:

PropertyDescriptor

HtmlTag

Un cas particulier est fait pour les acronymes de deux lettres dans laquelle les deux lettres sont capitalisées, comme indiqué dans l'identifiant suivant:

IOStream

La convention de notationsCamel, utilisé uniquement pour les noms de paramètres, capitalise la premier caractère de chaque mot sauf le premier, comme illustré dans les exemples suivants. Comme exemples montre également, deux lettres acronymes qui commencent un identifiant CamelCase sont à la fois en minuscules:

propertyDescriptor

ioStream

htmlTag

Mais néanmoins, ce sont des lignes directrices et conventions et non des lois. Si vous aimez prendre une autre convention, utilisez-la. Mais alors toujours et jamais mélanger.

Answer 2

La seule règle de StyleCop je peux trouver sur des constantes est SA1303. Il indique:

Le nom d'un champ C# constant doit commencer par une lettre majuscule.

Donc, soit Dpi soit DPI correspondrait à cette règle.

Microsoft says vous devriez Pascal le cas. À mon avis, les constantes devraient être toutes majuscules, donc je voudrais aller DPI. Microsoft utilise Xml dans les noms d'espace de noms, qui doivent être également codés en Pascal, donc Dpi serait le plus en accord avec l'utilisation propre par Microsoft des conventions de nommage.

Answer 3

Si vous suivez votre propre itinéraire, c'est un peu subjectif, mais j'espère que ce n'est pas le cas.La norme la plus facile UpperCamelCase que j'ai trouvé pour les équipes à suivre uniformément, si la cohérence est votre objectif stylistique primaire, est Dpi. Je ne dis pas que c'est mon préféré ou le plus lisible ou quelque chose comme ça. Je suis en train de dire que c'est la norme la plus facile à appliquer de manière cohérente pour une équipe disparate de personnes, et même par vous-même à travers les années au cours de laquelle vous utilisez cette convention. La raison en est que c'est assez robotisé et nécessite peu de réflexion. La façon de le faire est de vous demander comment vous écrivez ceci dans la convention de soulignement. Voulez-vous écrire comme ça? ... Si oui, vous traduisez le premier de chaque groupe de caractères séparés par un trait de soulignement en majuscules. Cela donne DPI. Mais sans doute presque tout le monde écrirait comme ça dans la convention de underscore:

dpi 

... donc la traduction robotisée, sans ambiguïté de underscore à UpperCamelCase devient Dpi. Même genre de chose si nous avons:

renderer_gl 

... la traduction robotisée, sans ambiguïté de underscore serait RendererGl. Maintenant, le bénéfice de ceci n'est pas nécessairement que c'est joli ou proche de la façon dont les humains le liraient et l'écriraient. C'est juste que, à condition de pouvoir régler comment écrire l'identifiant en underscore (ce que font la plupart des gens), même un robot peut alors le convertir en UpperCamelCase ou lowerCamelCase sans aucune ambiguïté. Donc, si une forte esthétique dans votre équipe est la cohérence et une convention où deux personnes différentes ne seront pas tentées d'utiliser des boîtiers différents, cela peut être le moyen le plus facile d'y parvenir. Dans notre cas, la cohérence était un objectif prioritaire puisque nous fournissions un kit de développement logiciel et nous ne voulions pas que notre API soit incohérente. Pour cela, il a aidé à établir une façon simple de choisir comment utiliser CamelCase qui ne nécessiterait pas beaucoup de réflexion ou d'impliquer toute forme d'ambiguïté.

Avec d'autres conventions, vous trouverez souvent beaucoup de cas spéciaux pour les abréviations/acronymes. "S'il s'agit d'un acronyme commun, traitez-le comme un mot.Si ce n'est pas, traitez-le comme un acronyme (toutes les majuscules) .Si c'est 2 lettres de longueur, traitez-le comme un acronyme.Si c'est 3+ lettres de longueur, traiter Si c'est un mot, s'il y a un L ou M à la fin, traitez-le comme un mot, sinon un acronyme à moins qu'il ne soit suivi d'un nombre ou précédé d'un nom propre. " Le cerveau peut faire du kaolin ici, et les équipes peuvent difficilement réussir à appliquer ces normes de manière cohérente.

Bien sûr, la cohérence n'est peut-être pas votre but le plus fort, mais si c'est le cas, je suggérerais cette convention.