“Действительно ли это” затенение является хорошей идеей?
Падеж переменных класса затенения общ в в 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;
}
}
Переменное затенение когда-нибудь хорошо?
Я рассматриваю реализацию правила кодирования, говоря, что "затенение не будет позволено". В простом случае выше его достаточно ясно, что продолжается. Включите немного больше кода, который делает что-то, и Вы рискуете пропускать "это" и представлять ошибку.
Каково общее согласие? Затенение запрета, позволяйте его иногда или позволяйте ему прокрутиться?
9 ответов
Я чувствую себя в безопасности с переменным затенением при использовании таких IDE, как Eclipse и IntelliJ IDEA, которые выделяют поля имеют другой цвет, чем локальные переменные, а также содержат полезные предупреждения о неправильном использовании локальных переменных.
На самом деле я предпочитаю правило «Затенение разрешено только в конструкторах и установщиках ». Все остальное не допускается.
Избавляет вас от необходимости именовать аргументы конструктора aValue и aTest только во избежание затенения.
Если вы используете eclipse, настройки его предупреждений могут быть установлены точно на этот параметр, кстати.
Верным случаем является то, что он предоставляет информативную подпись, поэтому те, кто обслуживает приложение, могут легко увидеть, какие поля передаются в вызове.
Шаблон Builder, однако, является лучшим решением с точки зрения ремонтопригодности.
Я не вижу проблем с этим кодом. Хорошо, что IDE помогает сократить объем кода, который вам нужно написать.
Хорошая IDE, такая как Eclipse, показывает вам в разных цветах и / или шрифтах атрибуты и переменные метода вашего класса. Из-за этого переменного затенения все в порядке.
Я фактически настроил свою установку Eclipse на выдачу предупреждений для каждой недостаточно квалифицированной переменной. Это гарантирует, что я никогда не забуду префикс переменных реализации с помощью this. . Это эффективно превентивно решило любую проблему, которая могла возникнуть в результате слежки.
Вы можете сделать это, выбрав «Настройки»> «Java»> «Компилятор»> «Ошибки / предупреждения»> «Стиль кода»> «Неквалифицированный доступ к полю экземпляра».
Основное оправдание правил стиля - сделать код читабельным как для исходного автора, так и для других, кому необходимо его поддерживать. В этом контексте удобочитаемость - это возможность легко понять, что на самом деле делает код, как на механистическом, так и на более глубоком семантическом уровне.
В общем, (помимо конструкторов и установщиков) скрытие переменных считается плохим стилем, потому что это заставляет случайного читателя ошибочно использовать локальные переменные для использования членов, и наоборот. (IDE, которая выделяет имена членов, как правило, смягчает это, но все же легко пропустить различие.) И (помимо конструкторов и установщиков) обычно существует четкое семантическое различие между локальным элементом и элементом с тем же именем, и лучше всего это можно отразить, используя разные имена.
Сеттеры и конструкторы немного отличаются во всех вышеперечисленных аспектах. Поскольку сеттеры (в частности) и конструкторы просты и стилизованы, скрытие показанной формы вряд ли вызовет путаницу у случайного читателя. В самом деле, я бы сказал, что использование только одного идентификатора для того, что по сути является одной и той же информацией, на самом деле может облегчить чтение кода.
Исходя из этого, я бы сказал, что скрытие в конструкторах и установщиках вполне приемлемо. Правило стиля, которое жестко настаивает на том, что вы не должны прятаться в этом контексте, является (IMO) педантичным и, возможно, контрпродуктивным. И это определенно не соответствует тому, что большинство программистов Java считают нормальной практикой.
Я все время занимаюсь «этой» слежкой. В сложных местах полезно использовать явное this , даже если оно ничего не затеняет. Это упрощает различие между локальными переменными и переменными класса с человеческой точки зрения (хотя тогда становится проблемой, что вы должны быть последовательны; использование this немного здесь и там, но не везде сбивает с толку) .
В Python у вас даже нет выбора: простой x всегда локален. Члены класса: self.x .
Shadowing может быть полезен в простом коде, таком как конструкторы, геттеры, сеттеры и т.п.
Однако использование описательных переменных действительно важно, поэтому вместо
this.name = name; попробуйте this.name = newName;
Кроме того, если у вас есть привычка включать this. в свой код, то это станет второй натурой и очень поможет в читабельности