Соглашение об именах с # для констант?
private const int THE_ANSWER = 42;
или же
private const int theAnswer = 42;
Лично я думаю, что с современными IDE мы должны использовать camelCase, поскольку ALL_CAPS выглядит странно. Что вы думаете?
@Peter, поскольку значение константы 42, я твердо верю, что это ссылка на Автостопом по Галактике.
@PeterMortensen Это креативно! Но такие имена, как itsEmployee и itsCostumer, могут вводить в заблуждение.
MSDN: условные обозначения заглавных букв msdn.microsoft.com/en-us/library/vstudio/ms229043(v=vs.90).a spx
Я предпочитаю theAnswer. Раньше был поклонником венгерской нотации, но с тех пор, как я научился не использовать ее, я люблю строго избегать каких-либо мета-указаний в именах. То же самое и с такими интерфейсами, как IInterface. Я предпочитаю Interfacable. Но при работе в команде надо было соблюдать правила :(
MSDN рекомендует использовать «TitleCase» для констант, так что это будет «TheAnswer» (хотя, как отмечали другие, вам обычно не следует ставить перед именами переменных префикс «The», поскольку он не добавляет никакого значения).
Почему Math.PI в верхнем регистре?
Проблема с ответами здесь в том, что примеры - это переменные, состоящие из одного или двух слов. Но когда вы сталкиваетесь с очень конкретным определением значения, которое используется во всем приложении, например Temporary_Employee_Subscription_January_Grace_Period, или чего-либо, что указывает на очень конкретное свойство категории в конкретном случае бизнес-логики, то читаемость определения ухудшается, когда удаление подчеркивания: TemporaryEmployeeSubscriptionJanuaryGracePeriod. Для меня это особый тип констант, который не похож на ваш обычный тип констант Enum.
Ответы 9
Оставьте венгерский язык венграм.
В этом примере я бы даже оставил окончательную статью и просто выбрал
private const int Answer = 42;
Это ответ или это ответ?
* Сделано редактирование как Паскаль строго правильным, однако я подумал, что вопрос требует большего ответа на жизнь, вселенная и все остальное.
В данном конкретном случае это ответ в. Но только потому, что я очень люблю читать Д. Адамса.
да, а в чем вопрос? и не кормите меня этим извинением за неудобства;)
Ах, но поскольку вы уже знаете ответ, вы не можете знать вопрос. Они исключают друг друга. (Спорим, вы это уже знали ;-)
Это правильный ответ на вопрос ОП. - Я бы дважды проголосовал за удаление The, если бы мог. :-)
Кто является венгром, говорит ли этот ответ, что им разрешено использовать другое соглашение?
Я считаю, что ALL_CAPS взят из способа работы C и C++. В этой статье здесь объясняется, как возникли различия в стилях.
В новой среде IDE, такой как Visual Studio, легко определить типы, область видимости и их постоянство, поэтому в этом нет строгой необходимости.
Программное обеспечение FxCop и Microsoft StyleCop поможет дать вам рекомендации и проверить ваш код, чтобы все работали одинаково.
Я по-прежнему использую верхний регистр для значений const, но это больше по привычке, чем по какой-либо конкретной причине.
Конечно, это позволяет сразу увидеть, что что-то является константой. Вопрос ко мне: действительно ли нам нужна эта информация? Помогает ли это нам как-нибудь избежать ошибок? Если я присвою значение константе, компилятор скажет мне, что я сделал что-то глупое.
Мой вывод: возьмите верблюжий кожух. Возможно, я тоже изменю свой стиль ;-)
Редактировать:
Это что-то венгерское пахнет не совсем верный аргумент, ИМО. Всегда должен быть вопрос: помогает или больно?
Бывают случаи, когда помогает венгр. Сейчас их не так много, но они все еще существуют.
Код читают гораздо чаще, чем пишут. Конечно, когда вы пишете код, компилятор не позволит вам присвоить константу. Но как насчет парня, который должен поддерживать ваш код через два года? Конечно, приятно иметь возможность сразу распознать константу.
Современные IDE выявляют множество проблем перед компиляцией. Я не думаю, что распознавание константы по имени важно, иначе не следует ли вам добавить какое-то специальное имя для переменных только для чтения?
Если задуматься, заглавные буквы, вероятно, пришли из макросов препроцессора, а не из констант (я никогда не использовал заглавные буквы для настоящих констант). В этом контексте имеет смысл отличать макросы от реального кода, потому что макрос вполне может быть выражением, а не постоянным значением, его расширение может вызвать побочные эффекты и так далее. Итак, вам нужно знать, когда вы используете макрос, а когда - константу. Лично я рад видеть обратную сторону макросов препроцессора, у них был большой потенциал, чтобы сделать код трудным для чтения.
@Tim: Согласен, в итоге макросы препроцессора принесли больше вреда, чем пользы. Мой самый любимый макрос PP: "#DEFINE Private Public" ;-)
@Tim: стандартная библиотека Tempate C++ приняла строчные буквы для констант, например. std :: string :: npos (cplusplus.com/reference/string/string/npos). Таким образом, ALL_CAPS предназначен только для макросов и директив препроцессора, что делает его еще более глупым в C#.
На самом деле это
private const int TheAnswer = 42;
По крайней мере, если вы посмотрите на библиотеку .NET, какая IMO - лучший способ решить соглашения об именах, чтобы ваш код не выглядел неуместным.
Рекомендуемое соглашение об именах и использовании заглавных букв заключается в использовании пascalCasing для констант (у Microsoft есть инструмент с именем StyleCop, который документирует все предпочтительные соглашения и может проверять ваш источник на соответствие - хотя это немного тоже анально сохраняет вкусы многих людей). например
private const int TheAnswer = 42;
Соглашение об использовании заглавных букв в языке Pascal также задокументировано в Microsoft Рекомендации по проектированию каркаса.
На самом деле StyleCop - это «не продукт Microsoft», а «инструмент, разработанный очень увлеченным разработчиком в Microsoft (по вечерам и в выходные)». (См. Подробности в blogs.msdn.com/sourceanalysis/archive/2008/07/20/… и blogs.msdn.com/bharry/archive/2008/07/19/…). При этом в соглашениях об именах фреймворка Microsoft используется регистр Pascal для констант, поэтому инструмент просто обеспечивает соблюдение стандарта, который Microsoft делает публикует и одобряет.
@bdukes - я не говорил, что это продукт Microsoft, однако он довольно часто используется и поддерживается во всей организации (как бывший сотрудник, я использовал его за годы до того, как кто-либо за пределами Microsoft получил его в свои руки, поэтому Я хорошо знаю его наследие).
Стоит отметить, что вы можете легко отключить правила StyleCop и сделать это гибко для файлов, проектов и решений. Теоретически вы также можете добавить свои собственные правила. В теории (-:
Мне это не нравится, потому что первая буква обычно используется, чтобы указать, является ли переменная видимой извне или нет. В коде TheAnswer для меня выглядит как публичное свойство, а не как частная константа. Я бы предпочел использовать такие префиксы, как constTheAnswer и ConstTheAnswer.
Я бы выбрал нотацию TheAnswer, кроме случаев, когда значение равно 42, и в этом случае я бы определенно придерживался подхода ALL_CAPS.
Паскаль лучше, потому что он не требует _, который требует слишком больших усилий для постоянного ввода.
Разве частное поле не должно быть верблюжьим, если оно константное?
@MarkusMeyer Нет, точно так же, как имена и свойства методов, он должен быть «TitleCase», независимо от видимости.
В правилах Microsoft сказано: «Не используйте прописные буквы в именах полей»: msdn.microsoft.com/en-us/library/ta31s3bc.aspx
Это верно, например, для полей. Константы считаются статическими для целей именования. msdn.microsoft.com/en-us/library/x2dbyw72.aspx
На самом деле я предпочитаю здесь PascalCase, но по привычке я виноват в UPPER_CASE ...
Во-первых, венгерская нотация - это практика использования префикса для отображения типа данных параметра или предполагаемого использования. Соглашения Microsoft об именах для говорит нет венгерской нотации http://en.wikipedia.org/wiki/Hungarian_notationhttp://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
Это в значительной степени подводит итог.
Да, в венгерских обозначениях не все заглавные буквы.
В своей статье Константы (Руководство по программированию на 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 документирует свой общедоступные константы в библиотеке классов .NET как поля. Вот некоторые примеры:
- Int32.MaxValue
- String.Empty(на самом деле,
static readonly) - Math.PI
- Math.E
Первые два являются примерами PascalCasing. Третий, похоже, следует за Microsoft Условные обозначения заглавных букв для двухбуквенного акронима (хотя число Пи не является акрионимом). И четвертый, кажется, предполагает, что правило для двухбуквенного акрионима распространяется на однобуквенный акроним или идентификатор, такой как E (который представляет собой математическую константу ееm>).
Кроме того, в своем документе о правилах использования заглавных букв Microsoft прямо заявляет, что идентификаторы полей должны именоваться через PascalCasing, и приводит следующие примеры для MessageQueue.InfiniteTimeout и UInt32.Min:
public class MessageQueue
{
public static readonly TimeSpan InfiniteTimeout;
}
public struct UInt32
{
public const Min = 0;
}
Вывод: используйте PascalCasing для общедоступных констант (которые описаны как поля const или static readonly).
Наконец, насколько мне известно, Microsoft не поддерживает определенные соглашения об именах или использовании заглавных букв для идентификаторов частный, как показано в примерах, представленных в вопросе.
Разработчик, написавший эту статью, явно не соблюдал рекомендуемые Microsoft соглашения о стилях для C#.
Статья, на которую указывает этот ответ, была изменена. Константы теперь общедоступны и были переведены на PascalCased. Учитывая оба этих изменения, это не помогает ответить, должны ли частные константы быть PascalCased или camelCased.
Визуально верхний регистр - лучший вариант. Это так узнаваемо. Ради уникальности и не оставляя шансов гадать, голосую за 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 lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
}
Я тоже предпочитаю это, поскольку регистр Паскаля легко спутать со ссылкой на свойство.
@ bc3tech, рад, что мы согласны. Я обновил ответ примечанием.
Независимо от приведенных выше рекомендаций, я предпочитаю UPPER_CASE и для констант, так как это значительно упрощает их идентификацию по сравнению с любыми другими случаями.
@usefulBee "SNAKE_CASE" категорически не рекомендуется в C#; Это неверный ответ. Правильный регистр для констант в C# - "TitleCase".
@ BrainSlugs83, я не думаю, что здесь правильно или неправильно; все сводится к предпочтениям и тому, что делает код более понятным.
@usefulBee Согласен. Но все же хорошо отметить, как это написано консенсус. В последнее время я делал много кода Ruby, и я думаю, что SCREAMING_SNAKE_CASE имеет смысл: совершенно очевидно, что это что-то особенное, и вам даже не нужно навести курсор мыши / перейти к определению, чтобы узнать, о чем он. Вы сразу это узнаете.
@mmiika: что означает "the" в этом примере? Это как в «Автостопом по галактике» или это перенесено из какого-то стандарта кодирования C++? (Например, старая структура C++ для Macintosh, THINK C [и более поздние версии, Symantec C++], использовала префикс «its» для элементов-указателей / ссылок и «the» для элементов скалярных значений.)