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

Question

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

По сути, большинство людей согласны, по крайней мере, с тем, что публичный член должен быть 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 показывает оба?

Спасибо.

Answer 1

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

1. Устраняет конфликты с именами параметров в верблюжьем корпусе - не нужно использовать «this»

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

Answer 2

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

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

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

Answer 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. все время - не только тогда, когда это необходимо - личные предпочтения, на самом деле ...

Answer 4

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

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

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