Что такое соглашение об именах статических полей С#?

Недавно я начал использовать ReSharper, который является фантастическим инструментом. Сегодня я столкнулся с правилом имен для статических полей, а именно с префиксом с подчеркиванием, т.е. 

private static string _myString;
  • Это действительно стандартный способ назвать статические переменные? Если это так, это личное предпочтение и стиль, или это имеет какой-то эффект более низкого уровня? Например, компиляция JIT и т.д.
  • Откуда этот стиль? Я всегда ассоциировал его с С++, это правильно?

Ответы

Ответ 1

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

Общие соглашения: camelCase, _camelCase и даже иногда похмелье из С++/MFC m_camelCase.

Если вы используете camelCase без префикса, поля поддержки свойств будут отличаться от имени свойства только в случае, что не является проблемой на С#, но не будет работать на языке, не учитывающем регистр, например VB.NET.

Так много людей, включая меня, любят использовать префикс подчеркивания, чтобы одни и те же стандарты могли использоваться на всех языках. По моему опыту, подчеркивание гораздо более распространено, чем m_.

Ответ 2

В соответствии с MSDN используйте Паскаль Кейс для статических полей. Я всегда хихикаю, когда MSDN и StyleCop противоречат друг другу:).

Итак, если вы следуете стандартам MSDN, правильный путь:

private static string MyString;

Ответ 3

На самом деле это стиль для частного поля, статического или нет. (По крайней мере, в ReSharper)

Ответ 4

В соответствии с StyleCop (и с настройками по умолчанию) правильный способ назвать большинство полей (как указано ниже) имеет строчный регистр буква в начале.

SA1306: FieldNamesMustBeginWithLowerCaseLetter

... Имена полей и переменных должны начинаться с буквы в нижнем регистре, если поле не является общедоступным или внутренним, const или не-частным и readonly. В этих случаях поле должно начинаться с буквы верхнего регистра.

См. также SA1309: FieldNamesMustNotBeginWithUnderscore.

Ответ 5

Проблема, с которой я столкнулась с руководством MSDN (используйте случай Pascal), заключается в том, что она не приводит к различию между частной статической переменной и общедоступным (нестатическим) свойством. Такая же проблема возникла бы для статических свойств - никакого различия между статическими и нестатическими.

Возможно, это преднамеренно?

Одним из путей этого было бы использовать тот же стандарт для статики, что и для нестатики, но всегда квалифицировать использование статики путем префикса с именем класса. Это может быть несколько дополнительных символов для ввода, но это делает код более удобочитаемым. Например:

public class Employee
{
    private static Int32 thresholdPercentage = 5;
    public static String TooMuchMessage = "Unacceptable pay rise - sorry!";

    private Decimal _salary = 0.0m;

    public void RaiseSalary(Int32 raiseAmountPercentage)  
    {
        if (raiseAmountPercentage > Employee.thresholdPercentage)
            throw new ApplicationException(Employee.TooMuchMessage);

        _salary *= 1 + (raiseAmountPercentage / 100);

        return;
    }
}

Ответ 6

Соглашение - это то, о чем говорят ваши стандарты кодирования вашей компании.

Ответ 7

1 - Не существует стандартного правила для имен переменных. Существуют требования к компилятору С# для разрешенных и не разрешенных (т.е. Не могут начинаться с числа), но правила стиля программирования на языке, как правило, остаются за программистами/организациями. ReSharper имеет заранее определенные правила стиля; однако они просто устанавливаются как значения по умолчанию в соглашении по конфигурации и могут быть изменены.

2 - Вы можете взглянуть на эту статью в Википедии, чтобы увидеть историю Camel Casing.

Ответ 8

Для статических полей я решил установить StaticUpperCamelCase (например, StaticPersonCache), поскольку он явно отличает его от переменной экземпляра. Это включает в себя частные статические поля, а также статические поля с другими модификаторами видимости.

Для статических переменных мне нечего беспокоиться о том, чтобы показать публичность/закрытость видимости через имя, а не указывать, как переменная работает между экземплярами. Кроме того, поскольку нет (и действительно не должно быть) многих Статических переменных, модификатор типа "Хугариан" не применяется часто.

Аналогично, для статических переменных потока ([ThreadStatic] или ThreadLocal) конвенция, которую я использую, - TS_UpperCamelCase (например. TS_Random). И снова этот "разрыв" с нормами передает очень важную информацию, которую другие разработчики могут не увидеть на первый взгляд. Таким образом, имя используется как предостерегающий флаг.

Я использую ReSharper и соответствующим образом скорректировал предупреждения/подсказки; большинство других соглашений об именах сохраняются в настройках ReSharper по умолчанию.

Мой выбор таких "нестандартных" условностей для статических/поточно-статических полей (примечание: Microsoft использует TS_ в некотором коде в библиотеке .NET), потому что я столкнулся с более чем "quirk" из-за неправильной идентификации переменных Static/ThreadStatic/Instance: это намного сложнее сделать с StaticX, TS_X, _x.