Когда вы используете ключевое слово «это»?

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

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

Я обычно подчеркиваю поля с помощью _, поэтому на самом деле не нужно его использовать. Кроме того, R # все равно имеет тенденцию к их рефакторингу ...

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

Я использую его только тогда, когда это абсолютно необходимо, то есть когда другая переменная затеняет другую. Например, здесь:

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Или, как указывает Райан Фокс, когда вам нужно передать это как параметр. (Локальные переменные имеют приоритет перед переменными-членами)

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

Один особенно удобный сценарий - это когда ваш объект вызывает функцию и хочет передать себя ей.

Пример:

void onChange()
{
    screen.draw(this);
}

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

Это зависит от стандарта кодирования, под которым я работаю. Если мы используем _ для обозначения переменной экземпляра, тогда «this» становится излишним. Если мы не используем _, я обычно использую его для обозначения переменной экземпляра.

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

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

Используйте this, когда есть двусмысленность, как в Пример Кори, или когда вам нужно передать объект в качестве параметра, как в Пример Райана. В противном случае нет причин использовать его, потому что возможность разрешить переменную на основе цепочки областей видимости должна быть достаточно ясной, чтобы в квалификационных переменных с ней не было необходимости.

Обновлено: документация C# по "this" указывает еще одно использование, помимо двух, которые я упомянул, для ключевого слова "this" - для объявления индексаторов

Обновлено: @Juan: Ха, я не вижу несогласованности в своих утверждениях - есть 3 случая, когда я бы использовал ключевое слово "this" (как описано в документации C#), и это те моменты, когда вы на самом деле необходимость это. Вставка «this» перед переменными в конструкторе, когда не происходит затенение, - это просто пустая трата нажатий клавиш и трата моего времени при его чтении, это не дает никакой пользы.

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

Я использую его всякий раз, когда StyleCop говорит мне об этом. StyleCop необходимо соблюдать. О, да.

Я не хочу, чтобы это прозвучало язвительно, но это не имеет значения.

Серьезно.

Посмотрите на важные вещи: ваш проект, код, работу, личную жизнь. Ни один из них не будет зависеть от того, используете ли вы ключевое слово «this» для определения доступа к полям. Ключевое слово this не поможет вам отправить товар вовремя. Это не уменьшит количество ошибок, это не окажет заметного влияния на качество кода или ремонтопригодность. Это не принесет вам прибавки и не позволит вам проводить меньше времени в офисе.

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

Я бы не стал беспокоиться об этом. Я бы просто позаботился о том, чтобы код был настолько эстетичным, насколько это возможно, в соответствии с вашими вкусами. Если вы спросите 10 программистов, как отформатировать код, вы получите около 15 различных мнений. Лучше сосредоточиться на том, как факторизуется код. Правильно ли абстрагировано? Подбирал ли я значимые имена для вещей? Много ли кода дублируется? Есть ли способы упростить вещи? Я думаю, что правильное решение этих вопросов окажет наибольшее положительное влияние на ваш проект, ваш код, вашу работу и вашу жизнь. По совпадению, это, вероятно, также заставит другого парня меньше всего ворчать. Если ваш код работает, легко читается и хорошо разложен, другой парень не будет внимательно следить за тем, как вы инициализируете поля. Он просто воспользуется вашим кодом, поразится его величию, а затем перейдет к чему-то другому.

В C# есть несколько вариантов использования ключевого слова это.

1. Чтобы квалифицировать участников, скрытых под похожим именем
2. Чтобы объект передавал себя в качестве параметра другим методам
3. Чтобы объект возвращался из метода
4. Объявить индексаторы
5. Объявить методы расширения
6. Для передачи параметров между конструкторами
7. Чтобы внутренне переназначить значение типа (структуры) значение.
8. Чтобы вызвать метод расширения в текущем экземпляре
9. Чтобы перейти к другому типу
10. Чтобы связать конструкторы, определенные в одном классе

Вы можете избежать первого использования, не имея в области видимости членов и локальных переменных с одинаковыми именами, например, следуя общим соглашениям об именах и используя свойства (случай Pascal) вместо полей (случай верблюда), чтобы избежать столкновения с локальными переменными (также верблюда дело). В C# 3.0 поля можно легко преобразовать в свойства с помощью автоматически реализуемые свойства.

Вот когда я его использую:

• Доступ к частным методам изнутри класса (чтобы различать)
• Передача текущего объекта другому методу (или как объект-отправитель, в случае события)
• При создании методов расширения: D

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

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

У меня есть привычка широко использовать его в Visual C++, так как это вызовет срабатывание IntelliSense. Я нажимаю клавишу '>', и я ленив. (и склонен к опечаткам)

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

[C++]

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

Итак, когда бы вы его использовали? Я только что просмотрел какой-то случайный код и нашел эти примеры (я не осуждаю, являются ли это действиями хороший или нет):

• Передача «себя» функции.
• Присвоение «себя» указателю или что-то в этом роде.
• Приведение, то есть приведение вверх / вниз (безопасное или иное), отбрасывание константности и т. д.
• Компилятор применяет значения.

Вы не должны использовать "this" без крайней необходимости.

За ненужное многословие ЕСТЬ штраф. Вы должны стремиться к тому, чтобы код был ровно столько, сколько нужно, а не больше.

Я использую его только при необходимости, за исключением симметричных операций, которые из-за полиморфизма одного аргумента должны быть помещены в методы одной стороны:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

[C++]

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

A a;
a = a;

Ваш оператор присваивания будет записан:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

this на компиляторе C++

Компилятор C++ будет молча искать символ, если не найдет его немедленно. Иногда в большинстве случаев это хорошо:

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

Но иногда Вы просто не хотите, чтобы компилятор угадывал. Вы хотите, чтобы компилятор выбрал правильный символ, а не другой.

Для меня, это время, когда внутри метода я хочу получить доступ к методу-члену или переменной-члену. Я просто не хочу, чтобы какой-то случайный символ был выбран только потому, что я написал printf вместо print. this->printf не скомпилировался бы.

Дело в том, что с устаревшими библиотеками C (§), устаревшим кодом, написанным много лет назад (§§), или чем-то еще, что могло произойти на языке, где копирование / вставка является устаревшей, но все еще активной функцией, иногда говоря компилятору не воспроизводить остроумие - отличная идея.

По этим причинам я использую this.

(§) для меня это все еще какая-то загадка, но теперь мне интересно, включен ли тот факт, что вы включаете заголовок в вашем источнике, является причиной того, что все символы устаревших библиотек C будут загрязнять ваше глобальное пространство имен

(§§) осознание того, что «вам нужно включить заголовок, но включение этого заголовка нарушит ваш код, потому что он использует какой-то тупой макрос с общим именем», - это один из тех моментов Русская рулетка в жизни кодера.

Другое несколько редкое использование этого ключевого слова - это когда вам нужно вызвать явную реализацию интерфейса из класса реализации. Вот надуманный пример:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

В ответе Якуба Штурца на его № 5 о передаче данных между подрядчиками, вероятно, нужно небольшое объяснение. Это связано с перегрузкой конструкторов, и это тот случай, когда использование this является обязательным. В следующем примере мы можем вызвать параметризованный конструктор из конструктора без параметров с параметром по умолчанию.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

Иногда я обнаружил, что это особенно полезная функция.

Я использую его для вызова Intellisense точно так же, как JohnMcG, но я вернусь и сотру "this->", когда закончу. Я следую соглашению Microsoft о добавлении к переменным-членам префикса «m_», поэтому оставлять его в качестве документации было бы просто излишним.

1 - Общая идиома установщика Java:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - При вызове функции с этим объектом в качестве параметра

notifier.addListener(this);

'это.' помогает найти члены в «этом» классе с большим количеством членов (обычно из-за глубокой цепочки наследования).

Нажатие CTRL + Пробел в этом не помогает, потому что оно также включает типы; где-как "это". включает ТОЛЬКО участников.

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

В плане стиля, если ты рейнджер-одиночка - решать тебе; если вы работаете в компании, придерживайтесь политики компании (посмотрите материалы в системе контроля версий и посмотрите, что делают другие люди). С точки зрения использования его для квалификации членов нет ни правильного, ни неправильного. Единственная ошибка - непостоянство - золотое правило стиля. Оставьте придираться к другим. Вместо этого потратьте свое время на размышления о реальных проблемах кодирования - и, очевидно, кодировании.

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

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

Для меня это имеет смысл сделать так, это упрощает чтение кода, когда вы различаете переменные класса и переменные метода.

Есть одно использование, которое еще не было упомянуто в C++, и это не обращение к собственному объекту или устранение неоднозначности члена из полученной переменной.

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

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

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

На этом этапе, без фактической замены типа, компилятор почти не имеет информации о том, каким может быть base<T> (обратите внимание, что специализация базового шаблона может превратить его в совершенно другие типы, даже неопределенные типы), поэтому он просто предполагает, что это тип. На этом этапе независимый вызов f, который кажется программисту совершенно естественным, представляет собой символ, который компилятор должен найти как член derived или во включающих пространствах имен - чего не происходит в примере - и он будет жаловаться.

Решение состоит в том, чтобы превратить независимое имя f в зависимое имя. Это можно сделать двумя способами, явно указав тип, в котором он реализован (base<T>::f - добавление base<T> делает символ зависимым от T, и компилятор просто предполагает, что он будет существовать, и откладывает фактическую проверку на второй пройти после подстановки аргументов.

Второй способ, намного более удобный, если вы наследуете от шаблонов, которые имеют более одного аргумента или длинных имен, - это просто добавить this-> перед символом. Поскольку реализуемый вами класс шаблона зависит от аргумента (он наследуется от base<T>), this-> зависит от аргумента, и мы получаем тот же результат: this->f проверяется во втором раунде после подстановки параметра шаблона.

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

Например

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(против)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

Кратко, к какому AABB относится right()? this добавляет немного осветлителя.