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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

Причины заблуждения

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

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

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

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

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

Реальные причины

Хотя я ценю работу компилятора, есть некоторые двусмысленности, которые я хотел бы сделать ООН-двусмысленности.

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

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

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

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

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

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

Что касается цитаты Брюса Эккеля из его «Мыслящей Java» ... Меня не впечатлили предвзятые сравнения Java / C ++, которые он продолжает делать в своей книге (и, как ни странно, отсутствие сравнения с C #), так что его личное точка зрения о this, сделанная в сноске ... Ну ...

Answer 3

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

Answer 4

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

Answer 5

"читаемость"

Я нашел полезным использование «this», особенно когда не используется IDE (небольшие быстрые программы)

Когда мой класс достаточно велик, чтобы делегировать некоторые методы новому классу, заменить «this» на «otherRef» очень просто с помощью самого простого текстового редактора.

е

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

После "рефакторинга"

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

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

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

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

Answer 6

менее читабельно , если, конечно, ваши ученики все еще не на зеленых экранах, как студенты здесь ... у элиты есть выделение синтаксиса.

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

Answer 7

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

Answer 8

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

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

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

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

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

Answer 9

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

Answer 10

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

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

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