Який прийнятий стиль використання ключового слова `this` на Java?


37

Я походжу з таких мов, як Python або Javascript (та інших, які менш об'єктно орієнтовані), і я намагаюся вдосконалити свої робочі знання щодо Java, які я знаю лише поверхнево.

Чи вважається поганою практикою завжди додавати thisдо поточних атрибутів екземпляра? Мені більш природно мені писати

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

ніж

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

оскільки це допомагає мені відрізняти атрибути екземплярів від локальних змінних.

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

У будь-якому випадку я вважаю за краще використовувати this. Чи буде це дивно, а не ідіоматично?


Ми використовуємо інструмент для того, щоб оцінити його в нашій компанії. Інструмент перезаписує код з нашим без цього, залежно від політики компанії. Тому коли-небудь кодуйте, як їм подобається, і код правильно відформатований під час фіксації.
deadalnix

2
"оскільки у кожного може бути більше функцій вкладення, отже, локальні змінні, що надходять із великих областей застосування." Крім того, той факт, що "це" насправді не є одним із місць некваліфікованої змінної, може походити з функції у JS.
Випадково832

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

4
В C # StyleCop хоче, щоб ви ставили, this.посилаючись на змінні, методи тощо. Я люблю це, я згоден з цим правилом. Я думаю, що це краще, ніж називати щось із підкресленням на початку. Я б дотримувався того самого правила, якби кодував Java.
Робота

Відповіді:


40

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

Це дійсно зовсім зайве.


7
Також: здоровий IDE повинен робити візуально відмінними поля та локальні змінні / параметри. Наприклад, у Eclipse (за замовчуванням) поля сині, а локальні змінні - чорні.
Йоахім Зауер

1
@Joachim Приємна точка, Eclipse навіть може змінити параметри кольорів і локальні змінні по-різному, якщо бажає користувач (однак це не за замовчуванням).
Ерік-Карл

3
Хоча я згоден, коли я натрапляю на код інших розробників (і будучи незнайомим на перший погляд), я вважаю this.набагато кориснішим. Можливо, це також тому, що у мене немає IDE, який кольорово кодує локальні / об'єктні змінні по-різному.
Бред Крісті

3
+1 для (перефразовуючи) "рефактор, якщо вам потрібно використовувати це, щоб визначити, що це член". Якраз те, що я хотів зазначити.
Ям Маркович

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

26

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

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

Я вважаю, що останнє речення Крісф мертве: будьте послідовні у використанні.


7
"Це також досить сильне нагадування щодо обсягу змінної для інших розробників." - причину, яку я схильний використовувати і люблю бачити this.в коді. На написання пішло півсекунди, і можна економити довгі хвилини, коли потрібно розібратися, чи дійсно хлопець перед тим, як ти насправді мав намір використовувати властивість pascal case, замість місцевого випадку з верблюдами, коли він зробив цю останню хвилину спалаху змін 20 редакцій тому.
scrwtp

18

Одне місце, яке я послідовно використовую "це", - це сетери та конструктори:

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

Крім цього, я не вважаю за потрібне додавати його. Під час читання тексту методу параметри та місцеві жителі знаходяться саме там - і досить легко відстежувати (навіть без допомоги IDE). Також місцеві жителі та поля мають різний характер (стан об'єкта порівняно з тимчасовим сховищем або параметром).

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

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

редагувати: я також в кінцевому підсумку використовую це в рівних, клонуваннях або в будь-якому іншому, що має параметр 'що' одного типу об’єкта:

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

8

Це дискусійно.

Приймаючи C # як аналогію, оскільки він має дуже схожий синтаксис та структуру на Java, ми виявляємо, що C # StyleCop має правило за замовчуванням, яке наполягає на тому, що ви додаєте this, але ReSharper має правило за замовчуванням, яке говорить про те this, що це зайве (яке воно є) і може бути вилучено.

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

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


8

Чи вважається поганою практикою завжди додавати це до атрибутів поточного екземпляра?

Так - одними, ні - іншими.

Мені подобається і використовувати thisключові слова у своїх проектах на Java та C #. Можна стверджувати, що IDE завжди буде виділяти параметри та поля різним кольором, однак ми не завжди працюємо в IDE - нам доведеться робити багато злиття / відмінностей / швидких змін у блокноті / перевірки фрагментів коду в електронній пошті . Це спосіб для мене легше визначити з першого погляду , де стан екземпляра змінюється - наприклад, розглянути деякі можливі проблеми паралелізму.


7

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

Методи ніколи не повинні бути більше кількох рядків коду, використовувати одну або дві локальні змінні, визначаючи, що стає тим, що стає простим; навіть із контекстом лише трьох рядків більшості різних інструментів. Якщо ваші методи занадто довгі і у ваших занять занадто багато відповідальності (часто це означає занадто багато полів), рішення полягає в тому, щоб розділити їх замість цього.

Я думаю, що "це" просто захаращує код. Особливо з сучасними IDE, які будуть по-різному забарвлювати локальні параметри / локальні змінні / поля.


5

Я думаю, ти відповів на власне запитання таким чином:

Мені більш природно мені писати

... this.foo ...

ніж

... foo ...

оскільки це допомагає мені відрізняти атрибути екземплярів від локальних змінних.

Якщо вам зручніше користуватися this.під час вдосконалення своїх робочих знань з Java, то будь-якими способами користуйтеся цією річчю ( я думаю, це, певним чином, знайоме «я» Python, з яким ви маєте відношення ).

Вся справа в тому, що, хоча люди наводять тверді / доречні аргументи щодо використання чи не використання this., це все ще звучить як дискусія, наведений приклад:

  • це робить зрозумілим призначення змінних порівняно з вами, слід переписати код, якщо не зрозуміло, що таке кожна змінна;
  • this.є зайвим, якщо ви проводите цілий день у IDE порівняно з I I виконуються огляди коду та роблять різницю в різних версіях, використовуючи компаратор без виділення синтаксису;
  • не введення тексту this.набирає мені важливих мілісекунд продуктивності порівняно з моєю оплатою натисканням та додаванням клавішthis. оплатою - це як підвищення заробітної плати: D;
  • тощо

Але суть полягає в тому, що наприкінці дня вона все-таки поновлюється до особистих уподобань та робочого середовища .


5

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

Однак я вважаю це цінним у кількох конкретних ситуаціях:

Перевизначення локальних параметрів - іноді необхідно вказати, що ви хочете використовувати змінну екземпляра, а не параметр / локальну змінну з тим самим іменем. Це досить часто в конструкторах, де ви хочете, щоб ім'я параметра відповідало внутрішньому імені змінної екземпляра, яке використовується для ініціалізації, наприклад

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

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

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.