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

Question

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

private static string _myString;

1. Это действительно стандартный способ именования статических переменных? Если это так, это просто личные предпочтения и стиль, или это оказывает какое-то влияние на более низкий уровень? Например, компиляция JIT и т. Д.
   
2. Откуда этот стиль? Я всегда связывал это с C ++, это правильно?

Answer 1

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

Распространенными соглашениями являются camelCase, _camelCase и даже иногда похмелье из C ++ / MFC m_camelCase.

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

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

Answer 2

Согласно MSDN , используйте Pascal Case для статических полей. Я всегда смеюсь, когда MSDN и StyleCop противоречат друг другу:).

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

private static string MyString;

Answer 3

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

SA1306: FieldNamesMustBeginWithLowerCaseLetter

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

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

Answer 4

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

Answer 5

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

Answer 6

Проблема, с которой я столкнулся в соответствии с рекомендацией 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;
    }
}

Answer 7

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

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

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

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

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

Answer 8

Другие ответы здесь немного сбивают с толку.

С .NET стандарт :

НЕ используйте PascalCasing в именах полей.
Правила именования полей применяются к статическим открытым и защищенным полям.

Таким образом, пример будет: MyStaticVariable, ActiveUserCount и т. Д.

Answer 9

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

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