Мифы C# о лучших практиках?

Мой коллега продолжает говорить мне о вещах, перечисленных в комментариях.

Я смущен. Кто-то может демистифицировать эти вещи для меня?

class Bar
{
    private int _a;

    public int A
    {
        get { return _a; }
        set { _a = value; }
    }

    private Foo _objfoo;

    public Foo OFoo
    {
        get { return _objfoo; }
        set { _objfoo = value; }
    }

    public Bar(int a, Foo foo)
    {
        // this is a bad idea
        A = a;
        OFoo = foo;
    }

    // MYTHS
    private void Method()
    {
        this.A    //1 -
        this._a   //2 - use this when inside the class e.g. if(this._a == 2)
        A         //3 - use this outside the class e.g. barObj.A
        _a        //4 - 
                  // Not using this.xxx creates threading issues.
    }
}
class Foo
{
    // implementation
}
5
задан Pratik Deoghare 12 April 2010 в 11:09
поделиться

5 ответов

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

Проблемы с потоками не имеют к этому никакого отношения. Путаница может быть вызвана тем фактом, что большинство статических членов реализованы таким образом, что они являются потокобезопасными, а статические члены не могут (!) Быть вызваны с помощью this. , поскольку они не привязаны к экземпляру.

10
ответ дан 18 December 2019 в 06:02
поделиться

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

4
ответ дан 18 December 2019 в 06:02
поделиться

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

Как говорит Лусеро, "это" не требуется, если только () нет столкновения имен. Однако некоторые люди любят включать "this", когда это не является строго обязательным, потому что они считают, что это улучшает читабельность / более четко показывает намерения программистов. На мой взгляд, это скорее вопрос личных предпочтений, чем чего-то еще.

Что касается "плохой идеи" в вашем методе "Bar": Ваш коллега может посчитать это плохой практикой по следующей причине: если метод сеттера для "A" будет изменен таким образом, чтобы иметь некоторый побочный эффект, то A=a; также вызовет этот побочный эффект, тогда как _a = a; просто установит частную переменную. На мой взгляд, лучшая практика - это осознание разницы, а не предпочтение одного другому.

Наконец, "проблемы с потоками" - это чепуха - AFAIK "this" не имеет никакого отношения к потокам.

3
ответ дан 18 December 2019 в 06:02
поделиться

Число 2 - это миф, который легко развенчать, упомянув об автоматических свойствах. Автоматические свойства позволяют вам определить свойство без опорного поля, которое автоматически генерируется компилятором. Поэтому спросите своего коллегу, как он относится к автоматическим свойствам.

2
ответ дан 18 December 2019 в 06:02
поделиться

"Не использовать это .xxx создает проблемы с потоками "

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

"используйте это внутри класса, например if (this._a == 2)"

не соответствует тому, чего вы хотите достичь. Кажется, ваш коллега говорит, что всегда ссылается на частное поле, что мне не кажется разумным. Часто вы хотите получить доступ к свойству public , даже внутри класса, поскольку получатель может изменять значение (например, свойство типа List может возвращать новый экземпляр List, когда список имеет значение null, чтобы избежать null ссылочные исключения при доступе к свойству).

8
ответ дан 18 December 2019 в 06:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: