Соглашения о присвоении имен для членов парламента, не занимающих официального поста [закрытых] типов.NET

Рекомендации по структуре .Net допускают использование префиксов _ или m_ в именах закрытых полей, поскольку в них нет указаний по закрытым полям. Если вы посмотрите на BCL в отражателе, вы заметите, что префикс является наиболее распространенным шаблоном.

Справочная страница для именования полей находится здесь . Обратите внимание, что в правилах указано использование только для общедоступных и защищенных полей. Частные поля просто не покрываются.

Никакие соглашения не запрещают вам использовать допустимые имена идентификаторов. Важно быть непротиворечивым . Я использую «_» для всех частных переменных, хотя «правильный способ» (например, ReSharper), кажется, требует, чтобы вы объявляли их, начиная с строчной буквы, и различать параметры и члены посредством использования «this».

Да, соглашение об именах, применяемое StyleCop (которое обеспечивает соблюдение правил кодирования MS), - «без подчеркивания, верблюжий регистр» для полей частных экземпляров.

Следует отметить, что постоянные / статические поля, доступные только для чтения, имеют соглашение об именах «Pascal case» (должны начинаться с верхнего регистра, но не должны быть заглавными).

Другие соглашения об именах - это пережитки стиля C ++, который был начальным стилем, который использовался для написания кода C # с тех пор, как появилась команда C #.

Важное примечание: будете ли вы использовать этот стиль кодирования или нет, полностью зависит от команды разработчиков. Гораздо важнее, чтобы каждый в команде использовал один и тот же стиль, чем какой-либо конкретный стиль.
OTOH, MS выбрала этот стиль после долгих раздумий, поэтому я использую его как тай-брейк. Если нет особой причины идти тем или иным путем со стилем кодирования, я иду тем же путем, что и StyleCop.

Есть две статьи MSDN ( здесь и здесь ) о правилах проектирования, которые также содержат соглашения об именах. Жаль, что они ограничены «общедоступными» вещами. Они не предлагают рекомендаций по именованию непубличных вещей, и, насколько мне известно, Microsoft не предоставляет официальных рекомендаций по именованию для непубличных.

StyleCop (инструмент Microsoft) против использования подчеркивания в именах. Я слышал от разработчиков две причины, по которым они предпочитают использовать подчеркивание:

• он четко отмечает непубличные члены (введите _, и intellisense покажет вам все непубличные).
• он предотвращает конфликты между локальными переменными (которые часто также записываются в camelCase), параметрами метода и закрытыми полями.

ИМО, и другое - хорошая причина для использования символа подчеркивания, однако мне не нравится, как он выглядит в моем коде, поэтому я его тоже не использую. Я предпочитаю использовать только camelCase, когда это возможно, и добавляю this. в случае конфликтов с локальными переменными или параметрами метода.

Мы просто стараемся поддерживать единообразный стиль кодирования внутри команды и проекта.

Я действительно не верю, что есть ЛУЧШИЙ способ регистрировать переменные и методы. Важно то, что вы и ваша команда последовательны. Соглашения об именах .NET великолепны в том виде, в каком их определяет Microsoft, но некоторые люди предпочитают другие соглашения ...

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

Я обычно ставлю перед закрытыми переменными-членами знак подчеркивания.

Это просто упрощает их обнаружение, когда вы пытаетесь прочитать код, и это разрешено рекомендациями Microsoft:

public class Something
{
    private string _someString = "";

    public string SomeString
    {
        get
        {
            return _someString;
        }
        set
        {
            // Some validation
            _someString = value;
        }
    }
}

Как уже говорили другие, более важно быть последовательным. Если вы работаете в команде, у которой есть стандарт кодирования, который делает что-то так же, как m_ , не пытайтесь быть бунтарем и сделайте свое другое. Это только усложнит жизнь всем остальным.

Даже в BCL вы видите много несоответствий с соглашениями об именах, некоторые классы имеют « _ », некоторые « m_ "и некоторые версии свойства только в паскальском регистре.

Подчеркивание - это хорошо, потому что вы предотвращаете случайное переполнение стека , хотя более поздние версии Visual Studio все равно предупреждают вас об этом. Они также появляются первыми в вашем intellisense, избавляя от необходимости вводить в код this.someProperty или выполнять поиск по всему списку.

Пока команда соглашается с одним стандартом, это не имеет большого значения, но, используя символы подчеркивания более 5 лет, я лично не хотел бы возвращаться к альтернативам.

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

ну, микрософт не принимает участия ни в одном из 2 вариантов. Если в Visual Studio инкапсулировать поле с помощью "refactor->Encapsulate Field..." для

private string _myVar

и

private string myVar

то оба варианта генерируют вот такой пролог

public string MyVar
{
    get { return myVar; }
    set { myVar = value; }
}

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

Обычно я никогда не использую приватные поля, за исключением очень специфических ситуаций. Я инкапсулирую приватные поля с помощью защищенных свойств. Это лучше для наследования и более понятно IMHO.