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

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

this.fieldName = fieldName

При присвоении поля.

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

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

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

public doSomething() {
    doThat(); //member method
}

у меня есть коллеги, которые предпочитают:

public void setFoo(String foo) {
    _foo = foo;
}

Если Вы собираетесь устранить необходимость добавить это. перед членскими переменными, инструменты статического анализа такой как checkstyle может быть неоценимым в обнаружении случаев, где членские переменные скрывают поля. Путем удаления таких случаев можно устранить необходимость использовать это во-первых. Это сказанное я предпочитаю игнорировать эти предупреждения в случае конструкторов и методов set вместо того, чтобы иметь необходимость придумать новые названия параметров метода:).

Относительно статических переменных я нахожу, что самые достойные IDE выделят их так, чтобы можно было сказать им независимо. Это также платит для использования соглашения о присвоении имен для вещей как статические константы. Инструменты статического анализа могут помочь здесь путем осуществления соглашений о присвоении имен.

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

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

С.Net точки зрения некоторые инструменты анализа кода, которые я использовал, видели "это" и сразу пришли к заключению, что метод не мог быть статичным. Это может быть что-то для тестирования с Java, но если это делает то же там, Вы могли бы пропускать некоторые улучшения производительности.

"Удобочитаемость"

я нашел полезными использование "это" особенно если не использование IDE (маленькие быстрые программы)

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

т.е.

//Before
this.calculateMass();
this.perfornmDengerAction();
this.var = ...
this.other = ...

После "осуществления рефакторинг"

// after
this.calculateMass();
riskDouble.calculateMass();
riskDouble.setVar(...);
this.other = ... 

, Когда я использую IDE, я обычно не использую его. Но я думаю, что это делает Вас вещью в большем количестве OO путь, чем просто использование метод.

class Employee {

        void someMethod(){
             // "this" shows somethings odd here.
             this.openConnectino() ; // uh? Why an employee has a connection???
             // After refactor, time to delegate.
             this.database.connect(); // mmhh an employee might have a DB.. well.. 
         }
     ... etc....
}

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

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

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

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

Я использую this по крайней мере по двум причинам:

причины Ошибок

мне нравится иметь последовательные стили кода при кодировании в C++, C, Java, C# или JavaScript. Я сохраняю меня с помощью того же стиля кодирования, главным образом вдохновленного Java, но вдохновленного другими языками.

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

Мой код скорее verbous. Мои имена методов могут быть долгими (или не). Но они всегда используют полные имена, и никогда уплотняемые имена (т.е. getNumber(), не getNbr()).

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

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

Настоящие причины

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

, Например, я (почти) никогда не использую using namespace MyNamespace. Я или использую полное пространство имен или использую псевдоним с тремя буквами. Я не люблю неоднозначностей и не люблю его, когда компилятор внезапно говорит мне, что существуют также функции "печать", сталкивающаяся вместе.

Это - причина, я снабжаю префиксом функции Win32 глобальным пространством имен, т.е. всегда пишу ::GetLastError() вместо GetLastError().

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

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

Мое Заключение?

, В целом, эта проблема имеет главным образом стиль, и с подлинными техническими причинами. Я не захочу смерть кого-то не запись this.

Что касается кавычки Bruce Eckel от его "Думающего Java"... Я не был действительно впечатлен смещенным Java/C++ сравнений, который он продолжает делать в своей книге (и отсутствие сравнения с C#, странно), таким образом, его персональная точка зрения [приблизительно 1 113], сделанные в сноске... Хорошо...

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

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

int f();

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

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

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

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

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

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

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

Более читаемый, я думаю. Я делаю это Ваш путь по точно тем же причинам.

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

class SomeClass{
    int x;
    int y;

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

Это облегчает говорить то, что аргумент устанавливает что участник.

3 Причины (Иск номекса НА [1 118])