Является ли "this" затенением хорошей идеи?
Случай затенения переменных класса распространен в Java. Eclipse с радостью сгенерирует этот код:
public class TestClass {
private int value;
private String test;
public TestClass(int value, String test) {
super();
this.value = value;
this.test = test;
}
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
public String getTest() {
return test;
}
public void setTest(String test) {
this.test = test;
}
}
Является ли переменная затенение когда-либо приемлемой?
Я рассматриваю реализацию правила кодирования, в котором говорится, что "затенение не будет разрешено". В простом случае выше достаточно ясно, что происходит. Добавьте еще немного кода, который что-то делает, и вы рискуете потерять "this" и введя ошибку.
Каков общий консенсус? Запретить затенение, разрешить его иногда или позволить ему катиться?
Ответы
Ответ 1
На самом деле я предпочитаю директиву. "Тени можно разрешить только в конструкторах и сеттерах ". Все остальное не разрешено.
Сохраняет проблемы с именами конструкторов конструктора aValue
и aTest
, чтобы избежать затенения.
Если вы используете eclipse, его настройки предупреждений могут быть точно установлены на этот параметр BTW.
Ответ 2
Я чувствую себя в безопасности при переменной тени при использовании IDE, таких как Eclipse и IntelliJ IDEA, которые выделяют поля в разных цветах, чем локальные переменные, а также предоставляют полезные предупреждения о неправильном использовании локальной переменной.
Ответ 3
Тень может быть полезной в простом коде, таком как конструкторы getters seters и что-то в этом роде.
Однако использование дескриптивных переменных действительно важно, поэтому вместо использования
this.name = name;
попробуйте this.name = newName;
Кроме того, если у вас есть привычка включать this.
в свой код, он становится второй натурой и немного помогает с читабельностью
Ответ 4
Хорошая среда IDE, например Eclipse, показывает вам в разных цветах и /или шрифтах атрибуты и переменные метода вашего класса. Becaus этого переменного теневого копирования в порядке.
Ответ 5
Я действительно настроил свою установку Eclipse для выдачи предупреждений для каждой недокачаемой переменной. Это гарантирует, что я never забудет префикс переменных реализации с помощью this.
. Это эффективно устранило любую проблему, которая может возникнуть в результате затенения.
Вы можете сделать это с помощью настроек > Java > Компилятоp > Ошибки/Предупреждения → Стиль кодa > Неквалифицированный доступ к полю экземпляра.
Ответ 6
Я выполняю "this" затенение все время. В сложных местах полезно использовать явный this
, даже если он ничего не тень. Это облегчает различие между локальными и классовыми переменными с точки зрения человека (хотя тогда становится проблемой, что вы должны быть последовательными, а немного меньше и здесь, но не везде, запутывает).
В Python у вас даже нет выбора: plain x
всегда локальный. Элементы класса self.x
.
Ответ 7
Основное обоснование правил стиля - сделать код читаемым, как оригинальному автору, так и другим, которым необходимо его поддерживать. В этом контексте читаемость заключается в возможности легко понять, что на самом деле делает код, как на механистическом уровне, так и на более глубоком семантическом уровне.
В общем, (кроме конструкторов и сеттеров) переменное спряжение имеет тенденцию считаться плохим, потому что это заставляет случайного читателя ошибочно использовать локальные жители для использования членов, и наоборот. (IDE, которая выделяет имена участников, как правило, смягчает это, но все же легко пропустить это различие.) И (помимо конструкторов и сеттеров) обычно существует четкое смысловое различие между локальным и членом с тем же именем и это лучше всего отражается в использовании разных имен.
Сеттеры и конструкторы немного отличаются друг от друга в каждом из приведенных выше замечаний. Поскольку сеттеры (в частности) и конструкторы просты и стилизованы, скрытие показанной формы вряд ли вызовет случайный читатель и путаницу. В самом деле, я бы сказал, что использовать только один идентификатор для того, что по существу является одной и той же информацией, на самом деле может сделать код более легким для чтения.
Исходя из этого, я бы сказал, что скрытие в конструкторах и сеттерах вполне приемлемо. Правило стиля, которое жестко настаивает на том, что вам следует избегать скрываться в этом контексте, является (ИМО) педантичным и, возможно, контрпродуктивным. И это, безусловно, не соответствует тому, что большинство Java-кодеров считают обычной практикой.
Ответ 8
Ну, я не вижу никаких проблем с этим кодом. Хорошо, что IDE помогает вам сократить количество кода, который вы должны написать.
Ответ 9
Допустимым является то, что он предоставляет сигнатурную подпись, поэтому те, которые поддерживают приложение, могут легко увидеть, какие поля передаются в Call.
Шаблон Builder, однако, является лучшим решением для удобства обслуживания.
Ответ 10
Тень всегда плохая. Назовите свои переменные после их объема (не типа), и вы сэкономите себя на хлопотах.