Когда НЕ ИСПОЛЬЗОВАТЬ 'this' ключевое слово?

Ответ 1

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

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

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

Ответ 2

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

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

internal sealed class Foo
{
    private Int32 bar = 42;

    private void Bar()
    {
        // Uncommenting the following line will change the
        // semantics of the method and probably introduce
        // a bug.  
        //var bar = 123;

        Console.WriteLine(bar);

        // This statement will not be affected.
        Console.WriteLine(this.bar);
    }
}

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

Ответ 3

Мое эмпирическое правило: никогда не используйте 'this', когда он избыточен. В этом случае 'this' является избыточным, поэтому я бы его избегал. Инструмент, подобный ReSharper, очень хорошо говорит вам, когда это так.

Ответ 4

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

Ответ 5

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

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

Ответ 6

Это прекрасно. Тем более, что ваш класс не имеет базового класса, а частные поля называются соответствующим образом. ReSharper считает, что this в вашем случае является избыточным.

Ответ 7

Должен ли я использовать "this" со всеми вхождениями переменных класса внутри класса?

В вашем конкретном случае NO.

Рассмотрим, однако, следующий пример:

class RssReader
{
    private String url;

    public bool FetchFeed (String url)
    {
        new XmlTextReader (url);

        // vs.

        new XmlTextReader (this.url);

        return true;
    }
}

Здесь вам нужно указать this для доступа к переменной экземпляра, которая имеет то же имя, что и аргумент метода.

Ответ 8

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

Ответ 9

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

Ответ 10

Хорошо, что касается меня, 'this' выглядит излишним при использовании с именами, начинающимися с "_". Это абсолютно законно в вашем примере.

Ответ 11

Вот как я смотрю на это. Когда вы вызываете элемент (будь то метод, свойство или поле) класса как такового, например DoMyThing(); или return Property; в пределах области экземпляра, необязательно, чтобы вы вызывали члена экземпляра. DoMyThing или Property также могут быть статическими членами.

public class Abc
{
    public static void Static()
    {
    }

    public Xyz Instance;

    public void Test() //instance scope
    {
        var xyz = Instance; //calls instance member
        Static(); //calls static member
    }
}

Для обоих из них (статический и экземпляр) я ничего не префикс. На самом деле мои варианты:

• не префикс вообще, как указано выше

  public void Test()
  {
      var xyz = Instance;
      Static();
  }
  

• префикс для членов только членов

  public void Test()
  {
      var xyz = this.Instance; // prefixes 'this'
      Static(); 
  }
  

• префикс только для статических членов

  public void Test()
  {
      var xyz = Instance; 
      Abc.Static(); //prefixes class
  }
  

• префикс в обоих случаях

  public void Test()
  {
      var xyz = this.Instance; // prefixes 'this'
      Abc.Static(); //prefixes class
  }
  

Этот ответ не означает, что один стиль лучше, чем другой. Это личное предпочтение. У каждого есть свои претензии на правильность и удобочитаемость.

Мой прием:

а. Мне для одного не нравится непоследовательный стиль 2. и 3.

б. 1. имеет преимущество, чтобы быть более читаемым для меня. Префикс делает его более понятным, чем намерение.

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

Лично я бы пошел с 1. И использую this или Abc экономно, когда меня вынуждают. Это более удобочитаемо для меня, польза для меня, которая достаточно хороша, чтобы компенсировать небольшую несогласованность, которую это могло бы вызвать.