Всегда ли префикс (авто) свойств с этим ключевым словом считается хорошей практикой?

Question

С тех пор, как я узнал об авто свойствах, я стараюсь использовать их везде. Раньше всегда был личный член для каждого свойства, которое я использовал в классе. Теперь это заменено свойством auto. Я использую свойство внутри своего класса так, как обычно использую обычное поле члена. Проблема в том, что свойство начинается с капитолия, что делает его немного странным при использовании его таким образом. Я не возражал, что свойства начинаются с капитолия раньше, потому что они всегда будут за «точкой». Теперь я обнаружил, что префиксирую все свойства, которые я использую внутри, с this., чтобы успокоить мое чувство.

Моя дилемма в том, что раньше я всегда был немного против префикса использования всех внутренних элементов с this., за исключением «необходимости» (как в установщике или конструкторе). Так что я как бы ищу второе мнение по этому поводу. Есть ли стандартный хороший способ сделать это? Должен ли я просто перестать жаловаться (у меня есть тенденция быть "муравейником" (голландское выражение))?

До:

class Foo
{
    private Bar bar;
    public Bar Bar { get { return bar; } }

    public Foo(Bar bar)
    {
        this.bar = bar;
    }

    public void DoStuff()
    {
        if(bar != null)
        {
            bar.DoMethod();
        }
    }
}

После того, как:

class Foo
{
    public Bar Bar {get; private set;}

    public Foo(Bar bar)
    {
        this.Bar = bar;
        // or
        Bar = bar;
    }

    public void DoStuff()
    {
        if(this.Bar != null)
        {
            this.Bar.DoMethod();
        }
        // or
        if(Bar != null)
        {
            Bar.DoMethod();
        }
    }
}

Обновление

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

Дополнительное примечание: тот факт, что это свойство также принято называть свойством так же, как класс (public Bar Bar { get; private set; }), также заставляет меня стремиться к префиксу. Каждый раз, когда я набираю Bar.DoMethod(), я чувствую, что это выглядит как статический метод. Даже если VS будет окрашивать Bar, если это статический метод, и у вас не может быть статического метода и метода экземпляра с одинаковой сигнатурой. Когда он окрашен, ясно, что это статический метод, но когда он не окрашен, не на 100% ясно, что это не статический метод. Например, вы можете просто пропустить оператор using, но также и потому, что я не привык связывать незакрашенный цвет с статическим вызовом или нет. Раньше я сразу видел это заглавными буквами первой буквы в случае члена или «точкой» в случае свойства (например, «точка» после foo в (Foo)foo.Bar.DoMethod()).

(Сложно выбрать «Принятый ответ» на данный момент)

Answer 1

Я настоятельно рекомендую использовать ' this. ', где это возможно. Руководство по разработке структуры рекомендует эту практику. Он позволяет вам знать сферу с точки зрения читабельности и помогает избежать глупых ошибок, о которых может сообщить компилятор во время компиляции.

Answer 2

Да, есть «стандартный способ сделать это»: заглавная буква и префикс this считаются хорошей практикой кодирования. Если вы используете какой-либо инструмент для проверки своего кода на соответствие правилам кодирования, например ReSharper или собственный StyleCop от Microsoft, он предупредит вас, если вы не используете ссылку this, или если вы не запускаете Ваша недвижимость с большой буквы.

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

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

Обновление : конечно, мнения разные. Мне нравится нажимать this., а затем, после точки, видеть только элементы, вместо того, чтобы видеть все ключевые слова при простом нажатии Ctrl + пробел без префикса. Это помогает мне. Но, в конце ( цитата отсюда ):

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

Дополнительные ссылки:
Microsoft об использовании заглавной буквы практически в любом имени и в свойствах.
Больше рекомендаций здесь .

Answer 3

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

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

Answer 4

В первом примере параметр bar лексически затеняет поле bar от экземпляра.Таким образом, вы должны использовать this для устранения неоднозначности.

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