На соглашениях о присвоении имен C# для членских переменных

Большинство переменных уровня временного класса начинаются с символа подчеркивания. Итак, myVariable на самом деле _myVariable. Многим людям не нравится изменять имя одним символом, потому что слишком легко ошибиться.

Нет ничего плохого в том, чтобы просто использовать myVariable и MyVariable. Это просто соглашение, и если все будут следовать ему, то, вероятно, все будет работать нормально.

Лично я, если это вообще возможно, не использую частные переменные и просто использую геттеры и сеттеры в свойстве. В большинстве случаев (но не всегда) доступ к частной переменной использовался, чтобы не разрешать доступ для записи в свойство.
Это можно решить с помощью:

public String MyVariable
{
   get;
   private set;
}

Как правило, я всегда вижу частные члены с ведущим _. (предполагаю, что это не автоматическое свойство)

private string _customerName;
public string CustomerName
{
    get{return _customerName;}
    set{_customerName = value;}
}

Конечно, окончательный вердикт - это решение вашей команды (предполагаю, что вы не делаете проект одинокого волка или работаете с полными идиотами)

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

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

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

Будьте осторожны с этим сценарием:

public class MyClass {
    public int Foo { get; private set; }

    public MyClass(int foo) {
        // oops, setting the parameter to itself, not the property
        foo = foo;
    }
}

Visual Studio предупредит вас о такой ситуации, но она не является незаконной и иногда может проскочить.

Основная проблема с предложенным соглашением об именах Intellisense будет использовать частную переменную над свойством. Во многих случаях это на самом деле не проблема (на самом деле, обычно это хорошо), но для тех немногих случаев, когда это так, соглашение, разделяющее два имени, полезно. Мне нравится m_ для частных переменных-членов и c_ для частных статических переменных.

Основная проблема с тем же именем и другим регистром заключается в том, что не все языки в .net чувствительны к регистру, то есть Visual Basic.

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

Как было сказано выше, это не влияет на сценарий поддерживающего частного члена.

Два самых популярных соглашения, которые я вижу, - это добавление к закрытым переменным-членам префикса _ или m_. Я лично предпочитаю соглашение m_, но до тех пор, пока оно единообразно во всем проекте / команде, мне все равно. Я не из тех, кто ввязывается в «религиозные войны» :)

Я брошу свою шляпу на ринг с тем, что я всегда использовал

class ClassName //Classes are PascalCase
{
    public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
    {
       _myProperty = myPropriety;
    }
    public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
    {
        int sampleVar; //local variables are camelCase
    }
    public int MyProperty { get { return _myProperty; } } // Properties are PascalCase

    private int _myProperty; // Private fields are camelCase and start with a _

Вот окончательное руководство от Microsoft.

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

Наслаждайтесь!

Если вы используете только C #, это не проблема, но если вы (или ваша команда / компания) также используете VB.Net (без учета регистра), то я бы рекомендовал Возможно, лучше не делать этого и в C #, чтобы соглашения об именах между разными языками не слишком сильно отличались.

Нет ничего плохого в этих соглашениях об именах.

Версия свойств на самом деле является рекомендуемым форматом в соответствии с рекомендациями по проектированию .Net framework.

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

Рекомендации по проектированию инфраструктуры .Net для членов типов

• http://msdn.microsoft.com/en-us/library/ms229012.aspx