Соглашение об именах 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 как поля. Вот несколько примеров:
- типа int32.Максвеллову
-
строку.Пусто (на самом деле,
static readonly
) - математика.ПИ
- математика.E
первые два являются примерами 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 не выступает за конкретные соглашения об именах или капитализации для частная идентификаторы, как показано в примерах, представленных в вопросе.
ALL_CAPS взят из способа работы C и c++, я считаю. Эта статья здесь объясняет, как возникли различия в стиле.
в новой среде IDE, такой как Visual Studio, легко определить типы, область и если они постоянны, поэтому это не обязательно.
на FxCop и Microsoft StyleCop программное обеспечение поможет дать вам рекомендации и проверить ваш код, чтобы все работали одинаково.