Соглашение об именах C# для констант?

private const int THE_ANSWER = 42;

или

private const int theAnswer = 42;

лично я думаю, что с современными IDEs мы должны пойти с camelCase, поскольку ALL_CAPS выглядит странно. А ты как думаешь?

9 ответов


рекомендуемое соглашение об именовании и капитализации-использовать оболочку Pascal для констант (у Microsoft есть инструмент с именем StyleCop это документирует все предпочтительные соглашения и может проверить ваш источник на соответствие - хотя это немного слишком анально внимательный для вкусов многих людей). например,

private const int TheAnswer = 42;

соглашение о капитализации Pascal также задокументировано в Microsoft Основные Принципы Проектирования


на самом деле, это

private const int TheAnswer = 42;

по крайней мере, если вы посмотрите на библиотеку .NET, которая IMO - лучший способ решить соглашения об именах, поэтому ваш код не выглядит неуместным.


визуально, верхний регистр-это путь. Это так узнаваемо. Ради уникальности и не оставляя шансов угадать, Я голосую за UPPER_CASE!

const int THE_ANSWER = 42;

Примечание: верхний регистр будет полезен, когда константы будут использоваться в одном файле в верхней части страницы и для целей intellisense; однако, если они будут перемещены в независимый класс, Использование верхнего регистра не будет иметь большого значения, например:

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;
 }

Я по-прежнему использую верхний регистр для значений const, но это больше по привычке, чем по какой-либо конкретной причине.

конечно, это позволяет сразу увидеть, что что-то является const. Вопрос ко мне: действительно ли нам нужна эта информация? Помогает ли это нам каким-либо образом избежать ошибок? Если я назначу значение const, компилятор скажет мне, что я сделал что-то глупое.

мой вывод: идите с корпусом верблюда. Возможно, я тоже изменю свой стиль. ;-)

Edit:

Что-то пахнет венгерский не очень веским аргументом, ИМО. Вопрос всегда должен быть таким: помогает это или причиняет боль?

бывают случаи, когда венгерский помогает. Сейчас их не так много, но они все еще существуют.


во-первых, венгерская нотация-это практика использования префикса для отображения типа данных параметра или предполагаемого использования. Соглашения об именах Microsoft для говорит нет венгерской нотации http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

использование верхнего регистра не рекомендуется, как указано здесь: Случай Паскаля-приемлемая конвенция и крик ШАПКИ. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft также заявляет здесь, что верхний регистр может использоваться, если это сделано для соответствия существующей схеме. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

Это в значительной степени подводит его.


оставьте венгерский венграм.

в примере я бы даже оставил окончательную статью и просто пошел с

private const int Answer = 42;

Это ответ или ответ?

*сделал редактирование как Паскаль строго правильным, однако я думал, что вопрос искал больше ответа на жизнь, Вселенная и все остальное.


в статье Константы (Руководство По Программированию На C#) компания Microsoft приводит следующий пример:

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;
}

Итак, для констант, это появляется что Microsoft рекомендует использовать camelCasing. Но обратите внимание, что эти константы определены локально.

возможно, именование внешне видимых констант представляет больший интерес. На практике Microsoft документирует его общественные константы!--20--> в библиотеке классов .NET как поля. Вот несколько примеров:

первые два являются примерами PascalCasing. Третий, похоже, следует за Microsoft Соглашения О Капитализации для двухбуквенного аббревиатуры (хотя Пи не является акрионимом). И четвертый, похоже, предполагает, что правило для двухбуквенного акрионима распространяется на однобуквенную аббревиатуру или идентификатор, такой как E (который представляет математическую константу e).

кроме того, в своем документе соглашений о капитализации Microsoft очень прямо заявляет, что идентификаторы полей должны быть названы через PascalCasing и дает следующие примеры для объект messagequeue.InfiniteTimeout и тип uint32.Мин:

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Вывод:PascalCasing для публичных констант (которые описаны как const или static readonly поля).

наконец, насколько я знаю, Microsoft не выступает за конкретные соглашения об именах или капитализации для частная идентификаторы, как показано в примерах, представленных в вопросе.


Я на самом деле предпочитаю PascalCase здесь - но по привычке, я виновен в UPPER_CASE...


ALL_CAPS взят из способа работы C и c++, я считаю. Эта статья здесь объясняет, как возникли различия в стиле.

в новой среде IDE, такой как Visual Studio, легко определить типы, область и если они постоянны, поэтому это не обязательно.

на FxCop и Microsoft StyleCop программное обеспечение поможет дать вам рекомендации и проверить ваш код, чтобы все работали одинаково.