Всегда ли префиксация (авто)свойств с помощью ключевого слова this-считается хорошей практикой?


С тех пор как я узнал о свойствах автомобилей, я стараюсь использовать их везде. Раньше для каждой собственности, которую я имел, всегда был частный член, который я использовал бы внутри класса. Теперь это свойство заменено свойством auto. Я использую свойство внутри своего класса так, как обычно использую обычное поле члена. Проблема в том, что свойство начинается с Капитолия, что делает его немного странным imho при использовании его таким образом. Я не возражал, что недвижимость начинается с Капитолия раньше, потому что они всегда будут за "точкой". Теперь я обнаружил, что префиксую все свойства, которые я использую внутренне с 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.. До появления свойств auto я всегда был в значительной степени против префиксов с this. вместо конструкторов и сеттеров (как я уже упоминал ранее). Но теперь я просто больше ничего не знаю.

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

(на данный момент трудно выбрать "приемлемый ответ")

4 7

4 ответа:

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

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

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

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

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

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

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

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

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

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

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