Когда Вы используете “это” ключевое слово? [закрытый]

Вы не должны использовать "это", если Вы абсолютно не должны.

СУЩЕСТВУЕТ штраф, связанный с ненужным многословием. Необходимо бороться за код, который является точно, пока это должно быть, и больше.

1 - Общая идиома метода set Java:

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

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

notifier.addListener(this);

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

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

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

Удар, которому CTRL+Space не помогает с этим, потому что он также включает типы; тогда как 'это'. включает участников ТОЛЬКО.

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

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

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

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

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

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

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

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

Это причины, которые я использую this.

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

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

[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;
}

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

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

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

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

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

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

Любое время Вам нужна ссылка на текущий объект.

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

Пример:

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

В ответе turc's Jakub Е его № 5 о передающих данных между конструкторами, вероятно, мог использовать немного объяснения. Это находится в перегружающихся конструкторах и является одним случаем, где использование this обязательно. В следующем примере мы можем назвать параметризованного конструктора от конструктора без параметров с параметром по умолчанию.

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

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

[C++]

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

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

• Передача "себя" к функции.
• Присвоение "себя" к указателю или чему-то как этот.
• Кастинг, т.е./вниз кастинг (безопасный или иначе), выбрасывание constness, и т.д.
• Компилятор осуществил разрешение неоднозначности.

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

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

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАНИЕ: документация C# относительно "этого" указывает на еще одно использование помимо двух, которые я упомянул для "этого" ключевого слова - для объявления индексаторов

РЕДАКТИРОВАНИЕ: @Juan: Ха, я не вижу несоответствия в своих операторах - существует 3 экземпляра, когда я использовал бы "это" ключевое слово (как зарегистрировано в документацию C#), и те - времена когда Вы на самом деле потребность это. Засовывать "это" перед переменными в конструкторе, когда нет никакого продолжения затенения, является просто тратой нажатий клавиш и пустой тратой моего времени при чтении его, это не предоставляет преимущества.

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

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

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

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;
    }

}

Или поскольку Ryan Fox указывает, когда необходимо передать это в качестве параметра. (Локальные переменные имеют приоритет по членским переменным)

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

Серьезно.

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

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

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

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

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

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

Есть одно использование, которое еще не было упомянуто в 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 может быть (обратите внимание, что специализация базового шаблона может превратить его в совершенно другие типы, даже undefined types), поэтому он просто предполагает, что это тип. На этом этапе независимый вызов f , который кажется программисту совершенно естественным, представляет собой символ, который компилятор должен найти как член , производный или во включающих пространствах имен - что не случится в примере - и он будет жаловаться.

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

Второй способ, намного более удобный, если вы наследуете от шаблонов, которые имеют более одного аргумента или длинных имен, - это просто добавить this -> перед символом. Поскольку реализуемый вами шаблонный класс зависит от аргумента (он наследуется от base ) 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() ;
  }
} ;

(vs)

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 добавляет немного пояснения.