Руководство по именованию полей C #?

Question

Я собираюсь поработать над небольшим количеством кода C # самостоятельно, но я хочу убедиться, что я следую наиболее широко принятым соглашениям об именах на случай, если я захочу привлечь других разработчиков, выпустить свой код или продать свойкод.Прямо сейчас я следую соглашению об именах, которое Microsoft установило, поскольку они кажутся наиболее широко принятыми.Единственная вещь, которую они не упоминают, это названия частных полей.По большей части я видел их имена в camelCase, как защищенные поля, однако это создает проблему, поскольку имена параметров должны быть в camelCase.Возьмем, к примеру, следующий конструктор:

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Теперь, если я использую camelCase для приватных полей, возникает конфликт имен, если я не использую «this» для доступа к полям класса (что я считаю противбольшинство стандартов не упоминать означает больше печатать).Одно из решений состоит в том, чтобы дать параметру другое имя, но это не имеет логического смысла давать одинаковые данные двум различным именам.Единственное другое решение, которое я знаю об этом, было распространено в кодировании C ++ - это дать частным членам подчеркивание в начале (_camelCase).Является ли это решение общепринятым с C # кодированием?Есть ли другое решение этой проблемы (например, только использование свойств (которые используют PascalCase) для доступа к полям, даже в самом классе)?

Answer 1

_camelCase для полей - это то, что я видел (это то, что мы используем у нас, и Microsoft предпочитает .NET Framework ).

Мое личное оправданиеиспользование этого стандарта заключается в том, что легче набрать _ для идентификации частного поля, чем this.

Например:

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

по сравнению

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

Я считаю, что первый текст гораздо проще набрать, и он не позволяет мне случайно назначить параметр с именем a вместо this.a.Это подтверждается Code Analysis Правило сопровождения, которое гласит:

• CA1500 Имена переменных не должны совпадать с именами полей.

Моя другая причина заключается в том, что this. является необязательным (resharper предлагает вам удалить их), если он не сталкивается с локальной переменной или именем параметра, что усложняет понимание того, какую переменную вы используете.Если у вас есть _ в начале всех приватных полей, то вы всегда знаете, какое поле имеет, а какое имеет локальную область действия.

Answer 2

Следуйте Правилам именования Microsoft . Правила для использования в полевых условиях указывают, что это должен быть camelCase, а не префикс. Обратите внимание, что общее правило не является префиксом; конкретное правило не должно заключаться в префиксе, чтобы различать статические и нестатические поля.

Не применять префикс к именам полей или статических имен полей. В частности, не применяйте префикс к имени поля, чтобы различать статические и нестатические поля. Например, неверно применять префикс g_ или s_.

и (из Общие правила именования )

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

РЕДАКТИРОВАТЬ : Я отмечу, что документы не являются специфическими в отношении частных полей, но указывают, что защищенные поля должны быть только camelCase. Я полагаю, что из этого можно сделать вывод, что любое соглашение для частных полей приемлемо. Конечно, общедоступные статические поля отличаются от защищенных (они пишутся с большой буквы). Мое личное мнение заключается в том, что защищенные / частные не достаточно различаются по объему, чтобы оправдать различие в соглашении об именах, тем более, что все, что вы, похоже, хотите сделать, это дифференцировать их от параметров. То есть, если вы будете следовать рекомендациям для защищенных полей, вам придется относиться к ним иначе, чем к частным полям, чтобы отличать их от параметров. Я использую this, когда обращаюсь к членам класса, чтобы прояснить различие.

РЕДАКТИРОВАТЬ 2

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

Answer 3

Обычно существует два широко используемых способа именования полей (всегда с использованием camelCase ):

Использование префикса подчеркивания

void F(String someValue) {
  _someValue = someValue;
}

Использование this. для доступа к полю и предотвращения конфликтов имен

void F(String someValue) {
  this.someValue = someValue;
}

Лично я предпочитаю позже, но я буду использовать любое соглашение, установленное организацией, в которой я работаю.

Answer 4

В нашем магазине мы запустили наш первый проект на C #, используя рекомендации Microsoft для частных пользователей, т.е.

camelCaseFieldName

Но вскоре мы столкнулись с путаницей между частными членами и параметрами и переключились на

_camelCaseFieldName

, который работал гораздо лучше для нас.

Закрытый член обычно имеет состояние, которое сохраняется вне вызова метода - подчеркивание, как правило, напоминает вам об этом.

Также обратите внимание, что использование синтаксиса AutoVariable для свойств может минимизировать потребность в частных полях поддержки, например

public int PascalCaseFieldName { get; set;}

. Для хорошего краткого набора стандартов, которые (в основном) следуют рекомендациям MS, проверьте нейминг-конвенция-и-программирование-стандарты --- лучшие практики

Answer 5

Краткий ответ: используйте _privateField, то есть используйте начальное подчеркивание для частных полей.

Длинный ответ: здесь идет ...

Давным-давно Microsoft предлагала использовать camelCase для полей. Смотрите здесь . Обратите внимание, когда этот документ был создан, 22.10.2008. Довольно древний.

Недавняя кодовая база Microsoft, однако, изображает другую картину.

1. Взгляните на C # стиль кодирования .NET-хранилища CoreFX github. № 3 - обсуждаемый вопрос. Вот соответствующая часть

   Мы используем _camelCase для внутренних и частных полей и используем readonly, где это возможно.

2. Также взгляните на стиль кодирования репозитория Roslyn , в котором конкретно говорится, что он соответствует соглашениям .NET CoreFX.
3. Еще раз взгляните на стандартную страницу поддержки .NET , которая также говорит (по крайней мере, на данный момент) о том же руководстве, что и .NET CoreFX.
4. CoreCLR также предлагает следовать тому же руководству, что и CoreFX.
5. Даже Репозиторий Winforms говорит об использовании этого же стандарта.
6. Я думаю, что сказал достаточно. Итак, в заключение, если вы хотите следовать руководству, которое предлагает Microsoft, я думаю, вы знаете, что делать; используйте начальное подчеркивание для частных полей, таких как: _privateField.

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

Answer 6

Как уже упоминалось, Microsoft Naming Guidelines доза не охватывает частные поля и локальные переменные именования.И вы не найдете последовательности в самой Microsoft.Если вы сгенерируете класс или шаблон Disposable в Visual Studio, он создаст что-то вроде

public MyClass(int value)
{
    this.value = value;
}

или

private bool disposedValue = false; // To detect redundant calls

protected virtual void Dispose(bool disposing)
{
    if (!disposedValue)
    {
        ...
    }
}

К счастью, все больше и больше кода было открыто Microsoft, поэтому давайте посмотримих репозитории, например ASP.NET Core MVC

private readonly IControllerActivator _controllerActivator;
private readonly IControllerPropertyActivator[] _propertyActivators;

Или .NET Core

private T[] _array;

Вы можете сказать, что это не такна самом деле Microsoft, но .NET Foundation.Справедливо, давайте взглянем на репозитории Microsoft :

private readonly MetricSeries zeroDimSeries;

Но вот древняя реализация Microsoft MVC

private IActionInvoker _actionInvoker;

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

Answer 7

Самое важное - выбрать один стандарт и придерживаться его. Проверьте C # Стандарт кодирования iDesign на IDesign (это ссылка на правой стороне). Это отличный документ, который охватывает такие вещи, как правила именования. Они рекомендуют использовать случай верблюда как для локальных переменных, так и для аргументов методов.

Answer 8

Philips Healtcare C # Стандарт кодирования

MSDN - Эрик Ганнерсон

Редактировать: я использую ключевое слово "this" для доступа к нестатическим членам в C # и Java.

Answer 9

Мы используем StyleCop для обеспечения согласованности всего кода.StyleCop используется в Microsoft для реализации общего набора рекомендаций по компоновке, удобочитаемости, удобству сопровождения и документированию исходного кода C #.

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

Чтобы ответить на ваш конкретный вопрос, частные поля должны быть в camelCase и иметь префикс «this».

Answer 10

Соглашение, которое я использую, чтобы различать переменные частного класса и параметры метода:

private string baseName;
private string prefixName;
private string suffixName;

public GameItem(string baseName, string prefixName, string suffixName)
{
    this.baseName = baseName;
    this.prefixName = prefixName;
    this.suffixName = suffixName;
}