Является ли "это" затенение хорошей идеей?

Question

Случай с теневыми переменными класса распространен в 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» и ввести ошибку.

Каков общий консенсус?Запретить слежку, разрешить иногда или запустить?

Answer 1

Я на самом деле предпочитаю рекомендацию "Затенение разрешено только в конструкторах и установщиках ". Все остальное не разрешено.
Избавляет вас от необходимости именовать аргументы конструктора aValue и aTest, чтобы избежать затенения.

Если вы используете eclipse, его настройки предупреждений могут быть точно установлены на эту опцию.

Answer 2

Затенение может быть полезно в простом коде, таком как конструкторы-установщики-установщики и тому подобное.

Однако использование описательных переменных действительно важно, поэтому вместо использования этого

this.name = name; попробуйте this.name = newName;

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

Answer 3

Я чувствую себя в безопасности с изменением теней при использовании IDE, таких как Eclipse и IntelliJ IDEA, которые выделяют поля разными цветами, чем локальные переменные, а также предоставляют полезные предупреждения о неправильном использовании локальной переменной.

Answer 4

Хорошая IDE, такая как Eclipse, показывает вам разными цветами и / или шрифтами атрибуты и переменные метода вашего класса. Потому что с этой переменной затенением все в порядке.

Answer 5

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

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

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

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

Answer 6

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

В Python у вас даже нет выбора: обычный x всегда локальный. Члены класса self.x.

Answer 7

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

Это можно сделать с помощью Предпочтения> Java> Компилятор> Ошибки / Предупреждения >> Стиль кода> Неквалифицированный доступ к полю экземпляра.

Answer 8

Затенение всегда плохо. Назовите свои переменные после их области (не типа), и вы избавите себя от хлопот.

Answer 9

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

Шаблон Builder, однако, является лучшим решением для удобства обслуживания.

Answer 10

Ну, я не вижу никаких проблем с этим кодом. Хорошо, что IDE помогает вам сократить объем кода, который вы должны написать.