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

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

В принципе, то, что большинство людей соглашается, по крайней мере, состоит в том, что публичный член должен быть PascalCased, в то время как частные члены должны быть lowerCamelCased.

Вопрос, который обычно вызывает дискуссию, заключается в том, следует ли префикс частных членов подчеркивать или что-то еще. Префикс нарушает несколько правил StyleCop (которые, очевидно, могут быть отключены)

Обоснование не префикса состоит в том, что вы должны использовать это. вместо префикса.

Проблема заключается в том, что я не понимаю, как это имеет значение? Я имею в виду, это не так, как вы не можете использовать это в публичном элементе в любом классе внутри класса.

Представьте себе класс Customer, выглядящий следующим образом:

class Customer
{
    private int age;

    public int Age
    {
        get { return this.age; }
        set { this.age = value; }
    }
}

(Очевидно, что в таком простом случае я мог бы использовать autoproperty, но это только пример).

Если бы я добавил второе свойство внутри этого класса, ничто не помешало бы мне ссылаться на него, используя this.Age(публичное свойство), а не this.age(частное поле). Иногда это может быть даже желательным, если на уровне получателя была применена какая-либо проверка или форматирование.

Кроме того, если некоторым другим свойствам моего класса необходимо было изменить возраст клиента, было бы целесообразно использовать свойство, а не поле поддержки непосредственно, так как сеттер мог также реализовать некоторые проверки бизнес-правил, правильно?

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

Спасибо.

Ответ 1

Вы совершенно правы. Это не так.

Использование this - это способ гарантировать, что вы используете член класса, в случае именования конфликтов (например, имя параметра, которое совпадает с именем поля).

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

Ответ 2

Я предпочитаю использовать правило "_" для частных полей, хотя оно не соответствует соглашениям MS:

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

Ответ 3

Использование this.age может помочь различать хранилище резервных копий вашего свойства Age и параметр Age для метода на вашем объекте:

public bool CheckIfOlderThan(int age)
{
   // in here, just using "age" isn't clear - is it the method parameter? 
   // The internal field?? Using this.age make that clear!
   return (this.age >= age); 
}

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

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

Ответ 4

Префикс частных полей с подчеркиванием - это в основном то же самое, что использовать "это". Однако подчеркивание быстрее используется, короче и элегантнее для меня (это происходит из Java, на который я верю).

Наличие одинаковых имен для параметров функций и частных полей кажется мне немного сложным. Не только однажды я забыл использовать "this", что привело к неприятному NullPointerException (да, я сделал java когда-нибудь...:)).

Насколько я знаю, это не нарушает правила FxCop, так как это не венгерская нотация.

Ответ 5

Я предлагаю это соглашение:

class Customer{
    private int Age_;
    public int Age{
        get{return Age_;}
        set{Age_ = value;}
    }
    public void MultiplyAge(int age){
        Age_ *= age;
    }
}

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

Конечное подчеркивание (например, Age_) обычно используется в С++ для частных полей, потому что начальное подчеркивание (например, _Age) может конфликтовать с компилятором. См. этот пост для получения дополнительной информации. Это не имеет значения для С#, конечно, но было бы неплохо связать соглашения между языками.
более низкий случай верблюда (например, возраст) чаще всего используется в .Net для представления локальных переменных и параметров метода.
Дифференциация, основанная только на случае (например, возраст и возраст), упрощает переносимость между языками, которые не заботятся о случае (например, VB.Net, в зависимости от параметров конфигурации).

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

class Customer{
  private int? Age_;
  public int Age{get{
    if(Age_ == null){
      // Really computationally expensive operation for retrieving and setting 
      // Age_ based on results from some external system goes here... or 
      // something like that.
    }
    return (int)Age_;
  }}
}