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

Question

Я видел совет где-то здесь на SO, чтобы не называть private/public переменные-члены так, чтобы они различались только в случае самого первого символа. Например:

private string logFileName;

public string LogFileName
{
    get
    {
        return logFilename
    ....

и: private System.Windows.Forms.MainMenu mainMenu;

и: DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();

и

public Version Version
{
    get;
    set;
}

и

    private void CheckPollingType(PollingType pollingType)
    {

Итак, я не правильно расслышал? Что-то не так с этими соглашениями об именах? Если да, то каковы лучшие способы сделать это? Ссылки, ссылки являются плюсом.

Спасибо.

Answer 1

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

Я бы просто рекомендовал следовать Соглашениям по присвоению имен для C #, предоставленным MSDN , а также Общим соглашениям по присвоению имен, предоставленным MSDN .

В частности, у них есть это, чтобы сказать о свойствах:

Делать имена свойств, используя существительное, словосочетание или прилагательное.

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

Не используйте свойства, соответствующие именам методов Get.

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

Назовите логические свойства с помощью утвердительной фразы (CanSeek вместо CantSeek).При желании вы также можете добавить префикс булевых свойств к Is, Can или Has, но только там, где оно добавляет значение.

Рекомендуется присвоить свойству то же имя, что и его типу.

Если у вас естьДля свойства, строго определенного для перечисления, имя свойства может совпадать с именем перечисления.Например, если у вас есть перечисление с именем CacheLevel, свойство, которое возвращает одно из его значений, также может называться CacheLevel.

Я думаю, если бы была веская причина противостоять тому, что вы предлагаете, ониупомянул бы это в своих рекомендациях.

Answer 2

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

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

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

public String MyVariable
{
   get;
   private set;
}

Answer 3

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

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

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

Answer 4

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

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 _

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

Answer 8

Так как это появляется среди самых популярных результатов поиска по теме, я тоже хотел поделиться своим предложением:

В дополнение к соглашению Pascal / camelCase для открытых / закрытых членов, я всегда выбираю имена переменных-членов, которые состоят из 2 или более слов , и имена локальных переменных, состоящие из одной строчной слово или даже просто буква.

public class MyCanvas : Canvas {
    public int CanvasId { get; private set; }
    private double canvasHeight; // member vars consist of 2+ words
    private double canvasWidth;

    public MyCanvas(int id) {
        CanvasId = id;
        double height = ...; // local vars consist of one word/letter
        canvasHeight = height;
    }
}

Это позволяет выбирать непротиворечивые и значимые имена переменных без «забавных» префиксов, таких как _, но также различать локальные переменные и переменные-члены.

Answer 9

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

Answer 10

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