Коли ви використовуєте ключове слово "це"? [зачинено]

Мені було цікаво, як інші люди використовують це ключове слово. Я схильний використовувати його в конструкторах, але я також можу використовувати його протягом усього класу в інших методах. Деякі приклади:

У конструкторі:

public Light(Vector v)
{
    this.dir = new Vector(v);
}

В іншому місці

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

У C # є кілька застосувань цього ключового слова.

1. Щоб кваліфікувати членів, прихованих за подібною назвою
2. Щоб об'єкт передав себе як параметр іншим методам
3. Щоб об'єкт повертався з методу
4. Декларувати індексатори
5. Декларувати методи розширення
6. Для передачі параметрів між конструкторами
7. Для внутрішнього переназначення значення типу (структура) .
8. Викликати метод розширення в поточному екземплярі
9. Накинути себе на інший тип
10. До ланцюжкових конструкторів, визначених в одному класі

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

Я не маю на увазі це звучати химерно, але це не має значення.

Серйозно.

Подивіться на важливі речі: ваш проект, ваш код, вашу роботу, особисте життя. Жоден із них не матиме успіху на тому, чи використовуєте Ви це слово для чи доступу до полів. Це ключове слово не допоможе вам доставити вчасно. Це не буде зменшувати помилки, це не матиме жодного помітного впливу на якість коду чи ремонтопридатність. Це не отримає вам підвищення, або дозволить вам менше часу проводити в офісі.

Це справді лише питання стилю. Якщо вам подобається "це", то використовуйте його. Якщо ні, то ні. Якщо вам це потрібно для отримання правильної семантики, тоді використовуйте її. Правда, кожен програміст має свій унікальний стиль програмування. Цей стиль відображає уявлення конкретного програміста про те, як повинен виглядати "найестетичніший код". За визначенням, будь-який інший програміст, який читає ваш код, матиме інший стиль програмування. Це означає, що завжди буде щось, що ви зробили, що іншому хлопцю не подобається, або зробили б інакше. У якийсь момент якийсь хлопець збирається прочитати ваш код і нарікати на щось.

Я б не хвилювався за це. Я би просто переконався, що код максимально естетично приємний відповідно до власних смаків. Якщо ви запитаєте 10 програмістів, як відформатувати код, ви отримаєте приблизно 15 різних думок. Краще зосередитись на тому, як розробляється код. Чи правильно абстрагуються речі? Я підбирав для речей значущі назви? Чи багато дублювання коду? Чи є способи я спростити речі? Правильне налаштування цих питань, я думаю, матиме найбільший позитивний вплив на ваш проект, ваш код, вашу роботу та ваше життя. Випадково це, ймовірно, також змусить іншого хлопця як мінімум нарікати. Якщо ваш код працює, його легко читати і добре враховувати, інший хлопець не збирається ретельно перевіряти, як ви ініціалізуєте поля. Він просто використовуватиме ваш код, дивуйтеся його величі,

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

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

}

Або як вказує Райан Фокс, коли вам потрібно передати це як параметр. (Локальні змінні мають перевагу перед змінними-членами)

Особисто я намагаюся завжди використовувати це, коли звертаюся до змінних членів. Це допомагає уточнити код і зробити його більш читабельним. Навіть якщо немає двозначності, хтось, читаючи мій код вперше, не знає цього, але якщо вони побачать, що це використовується послідовно, вони дізнаються, дивляться вони на змінну члена чи ні.

Я використовую його щоразу, коли звертаюся до змінної екземпляра, навіть якщо мені цього не потрібно. Я думаю, що це робить код більш зрозумілим.

Я не можу повірити, що всі люди, які кажуть, що використовувати це завжди, є "найкращою практикою".

Використовуйте "це", коли є двозначність, як у прикладі Корі або коли вам потрібно передавати об'єкт як параметр, як у прикладі Райана . Немає ніяких причин використовувати його інакше, оскільки можливість вирішити змінну на основі ланцюга області повинна бути достатньо зрозумілою, що кваліфікуючі змінні з нею повинні бути непотрібними.

EDIT: Документація C # на "це" вказує на ще одне використання, окрім двох, про які я згадував, для ключового слова "це" - для оголошення індексаторів

EDIT: @Juan: Так, я не бачу суперечливості в моїх заявах - є 3 випадки, коли я використовував би ключове слово "це" (як це зафіксовано в документації на C #), і це часи, коли вам це потрібно . Якщо "конструювати" це перед змінними в конструкторі, коли не відбувається затінення, це просто марно натискання клавіш, а марна трата мого часу під час його читання - це не приносить користі.

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

Будь-який час вам потрібно посилання на поточний об’єкт.

Особливо зручний сценарій - це коли ваш об'єкт викликає функцію і хоче передати себе в неї.

Приклад:

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

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

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

Ще одне дещо рідкісне використання цього ключового слова - це коли потрібно викликати явну реалізацію інтерфейсу з класу реалізації. Ось надуманий приклад:

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

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

Ось коли я його використовую:

• Доступ до приватних методів з класу (для розмежування)
• Передача поточного об'єкта іншому методу (або як об'єкт відправника, у разі події)
• При створенні методів розширення: D

Я не використовую це для приватних полів, тому що я префіксую назви змінних приватних полів із підкресленням (_).

[C ++]

Я погоджуюся з бригадою "використовуй, коли треба". Оформлення коду без необхідності з цим не є чудовою ідеєю, оскільки компілятор не попередить вас, коли ви забудете це зробити. Це вводить потенційну плутанину для людей, які очікують, що це завжди буде, тобто їм доведеться подумати над цим.

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

• Перехід «себе» до функції.
• Призначення "себе" покажчику чи щось подібне.
• Відливання, тобто лиття вгору / вниз (безпечне чи інше), відкидання чистоти тощо.
• Компілятор насильницького розголошення.

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

Я використовую його, коли у функції, яка приймає посилання на об'єкт того ж типу, я хочу чітко зрозуміти, на який об’єкт я маю на увазі, куди.

Наприклад

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

З першого погляду, на який right()посилається AABB ? thisДодає трохи освітлювач.

У відповіді Якуба Штурца його №5 про передачу даних між кондукторами, мабуть, можна було б використати невелике пояснення. Це в конструкторах, що перевантажують, і це єдиний випадок, коли використання thisобов'язкове. У наступному прикладі ми можемо викликати параметризований конструктор з конструктора без параметри з параметром за замовчуванням.

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

Я виявив це особливо корисною особливістю.

У мене з'явилася звичка використовувати його вільно у Visual C ++, оскільки це призведе до запуску IntelliSense, я натиснув клавішу '>', і я лінивий. (і схильний до друкарських помилок)

Але я продовжував його використовувати, оскільки вважаю зручним бачити, що я викликаю функцію члена, а не глобальну функцію.

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

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

Я використовую його лише в разі необхідності, за винятком симетричних операцій, які через поліморфізм одного аргументу повинні бути застосовані в методах однієї сторони:

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.

(§) для мене це все ще якась таємниця, але мені зараз цікаво, чи факт, який ви включаєте в свій джерело заголовок <windows.h>, є причиною того, що всі застарілі символи бібліотек C забруднюють ваше глобальне простір імен

(§§) розуміючи, що "вам потрібно включити заголовок, але що, включаючи цей заголовок, порушить ваш код, оскільки він використовує якийсь німий макрос із загальною назвою", - це один із моментів російської рулетки в житті кодера.

"це". допомагає знайти членів класу "цей" з великою кількістю членів (зазвичай це пов'язано з глибоким ланцюгом спадкування).

Якщо натиснути CTRL + пробіл, це не допомагає, оскільки воно також включає типи; де-як 'це'. включає членів ТОЛЬКО.

Я, як правило, видаляю його після того, як у мене з’явилося те, що я був після: але це лише мій стиль, який пробивається.

З точки зору стилю, якщо ви самотній рейнджер - ви вирішите; якщо ви працюєте в компанії, дотримуйтесь політики компанії (подивіться на матеріали в контролі джерел і подивіться, що роблять інші люди). З точки зору використання його для кваліфікації членів, це ні правильно, ні неправильно. Єдина неправильна річ - непослідовність - це золоте правило стилю. Залиште інших, що збирають нитку. Витратьте свій час на обдумування реальних проблем кодування - і, очевидно, кодування - натомість.

Я використовую його кожен раз, коли можу. Я вважаю, що це робить код читабельнішим, а більш читабельний код дорівнює меншій кількості помилок та більшої ремонтопридатності.

Коли у вас багато розробників, що працюють на одній базі коду, вам потрібні деякі вказівки та правила щодо коду. Де я працюю, ми вирішили використати "це" на полях, властивостях та подіях.

Для мене є сенс зробити це так, це полегшує читання коду, коли ви розмежовуєте змінні класу та змінні методу.

Це залежить від стандарту кодування, над яким я працюю. Якщо ми використовуємо _ для позначення змінної екземпляра, то "цей" стає зайвим. Якщо ми не використовуємо _, то я схильний використовувати це для позначення змінної екземпляра.

Я використовую його для виклику Intellisense так само, як JohnMcG , але я повернусь і стерну "this->", коли закінчу . Я дотримуюся конвенції Майкрософт щодо префіксації змінних членів "m_", тому залишати його як документацію було б просто зайвим.

1 - Загальна ідіома встановлення Java:

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

2 - При виклику функції з цим об'єктом в якості параметра

notifier.addListener(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перевіряється у другому раунді після заміни параметра шаблону.

Ви не повинні використовувати "це", якщо ви абсолютно не повинні.

Існує штраф, пов’язаний із зайвою багатослівністю. Ви повинні прагнути до коду, який є рівно стільки, скільки він повинен бути, і більше.