Соглашения об именах для частных членов типов .NET

Обычно, когда у меня есть частное поле внутри класса или структуры, я использую camelCasing, поэтому было бы очевидно, что он действительно частный, когда вы видите его имя, но в некоторых из кода моих коллег С# я вижу что они используют m_ в основном или иногда _, например, существует какое-то соглашение.

Соглашения об именах .NET не позволяют использовать символы подчеркивания для имен участников?

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

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

Является ли это спором?

Ответ 1

Технически, подчеркивание является нарушением соглашений .NET(или, по крайней мере, используется - см. поток комментариев), но сами программисты Microsoft часто используют символы подчеркивания, и во многих примерах в документации используются символы подчеркивания. Я думаю, что очень полезно иметь возможность сразу увидеть, какие переменные являются переменными-членами (поля) и локальными. Подчеркивание действительно помогает в этом. Он также прекрасно отделяет частные переменные-члены от локальных переменных в intellisense.

Пожалуйста, ознакомьтесь с этой очень полезной страницей для соглашений об именах .NET:

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

И вот страница с официальными рекомендациями Microsoft:

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx

Ответ 2

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

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

Ответ 3

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

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

public class Something
{
    private string _someString = "";

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

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

Ответ 4

хорошо, microsoft не принимает участия ни в одном из двух вариантов. Если в Visual Studio вы инкапсулируете поле, используя "refactor- > Encapsulate Field..." для

private string _myVar

private string myVar

оба из них генерируют свойство, подобное этому

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

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

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

Ответ 5

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

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

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

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

Ответ 6

См. последний параграф Руководство по использованию полей MS.

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

Ответ 7

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

Ответ 8

Я действительно не верю, что есть какой-либо BEST-путь к переменным и методам case. Важно то, что вы и ваша команда последовательны. Соглашения об именах .NET отлично подходят для Microsoft, но некоторые предпочитают другие соглашения...

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

Ответ 9

Да, соглашение об именах, применяемое StyleCop (которое применяет правила кодирования MS), не является символом underscores, case camel для частных полей экземпляра.

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

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

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

Ответ 10

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

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

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

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

Мы просто пытаемся сохранить стиль кодирования в команде и проекте.