Пишет "это". перед переменной экземпляра и методами хорошего или плохого стиля?

Question

Одна из моих неприятных (?) Привычек программирования на C ++ и Java - всегда предшествовать вызовам или доступам к членам с this. Например: this.process(this.event).

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

Мое обоснование:

1. Делает код более читабельным - Легче отличить поля от локальных переменных.
2. Упрощает отличение стандартных вызовов от статических вызовов (особенно в Java).
3. Помнит, что этот вызов (если цель не является конечной) может закончиться другой целью, например, в переопределенной версии в подклассе.

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

Примечание: я превратил его в CW, потому что на самом деле нет правильного ответа.

Answer 1

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

this.fieldName = fieldName

При назначении поля.

Тем не менее, если вам нужен какой-то способ дифференциации полей по какой-либо причине, я предпочитаю "this.fieldName" другим соглашениям, таким как "m_fieldName" или "_fieldName"

Answer 2

Это очень субъективная вещь. В Microsoft StyleCop есть правило, требующее квалификатора this. (хотя это связано с C #). Некоторые люди используют подчеркивание, некоторые используют странные венгерские обозначения. Я лично квалифицирую участников с this. , даже если это явно не требуется, чтобы избежать путаницы, потому что есть случаи, когда это может сделать код немного более читабельным.

Вы также можете проверить этот вопрос:
Какой префикс вы используете для переменных-членов?

Answer 3

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

if (0 == someValue)
{
    ....
}

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

if (someValue = 0)

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

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

Причины, которые я услышал, в основном сводятся к «наилучшей практике», обычно цитируемой Effective Java Джоша Блоха, которая имеет здесь огромное влияние. На самом деле, однако, Блох даже не использует его там, где даже я думаю, что он, вероятно, должен был бы помочь удобочитаемости! Опять же, кажется, что это больше похоже на то, что делают люди, которым говорят, что они делают это и не знают почему!

Лично я склонен согласиться с тем, что говорит Брюс Экель в «Размышлениях на Java» (3-е и 4-е издания):

---

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

---

сноска, p169, Мышление на Яве, 4-е издание

Довольно. Меньше значит больше, люди.

Answer 4

3 причины (костюм Nomex ON )

1) Стандартизация

2) Читабельность

3) IDE

1) Biggie Не относится к стилю кода Sun Java.

(Нет необходимости иметь другие стили для Java.)

Так что не делайте этого (на Java).

Это часть Java-вещи с синим воротничком: она всегда везде одинакова.

2) Читабельность

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

Если в классе слишком много методов или переменных, чтобы вы знали, является ли он членом или нет ... refactor.

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

Если вы хотите сказать, есть ли метод в родительском классе вашего класса или нет ... не забудьте указать @Override в ваших объявлениях, и пусть компилятор скажет вам, если вы не переопределяете правильно. super.xxxx () - это стандартный стиль в Java, если вы хотите вызвать родительский метод, в противном случае не указывайте его.

3) IDE Любой, кто пишет код без IDE, понимает язык и дает наброски на боковой панели, может делать это на своем собственном никеле. Понимая, что если это не 'чувствительный к языку, вы попали в ловушку в 1950-х. Без графического интерфейса: в ловушке в 50-х.

Любая приличная среда или редактор сообщит вам, откуда взялась функция / переменная. Даже оригинальный VI (<64 КБ) будет делать это с CTags. <em>просто нет оправдания для использования дрянных инструментов. Хорошие отдаются бесплатно!

Answer 5

Иногда мне нравится писать такие классы:

class SomeClass{
    int x;
    int y;

    SomeClass(int x, int y){
        this.x = x
        this.y = y
    }
}

Это упрощает определение аргумента, устанавливающего какой член.

Answer 6

Более читабельно, я думаю. Я делаю это по-твоему по тем же причинам.

Answer 7

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

Answer 8

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

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

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

Answer 9

Есть веская техническая причина, чтобы предпочесть использовать или избегать this - они не всегда эквивалентны.

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

int f();

template <typename T>
struct A
{
  int f();
};

template <typename T>
struct B : A<T>
{
  int g()
  {
    return f();
    return this->f();
  }
};

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

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

Answer 10

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