Использование "this" в Java против коротких имен параметров

ProgramBox

Использование «this» в Java против коротких имен параметров

Post author:admin
Запись опубликована:4 мая, 2023
Post category:Вопросы по программированию

#java #parameters #this

#java #параметры #это

Вопрос:

Что вы предпочитаете и почему?

 public void setPresenter(Presenter presenter) {
    this.presenter = presenter;
}

public void setPresenter(Presenter p) {
    presenter = p;
}

Ответ №1:

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

Вам не нужно придумывать два имени переменных для каждого поля.
«Извне» ясно, что представляет аргумент.
Это действительно стандартный подход.

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

Ответ №2:

Я предпочитаю this — этот класс иллюстрирует, почему

 class foo {

    int value;
    int otherValue;

    void setValue(int i) {
        value = i;
    }

    void setOtherValue(int i) {
        otherValue = i;
    }

    // uhh what? 
    void setBoth(int i, int j) {
        // which one should be first? oh, you guessed and got it wrong? tooooo bad!

    }


}

1. Это ужасный и совершенно надуманный пример.

2. Я не слишком уверен, в чем здесь проблема, но я предполагаю, что двусмысленность в setBoth заключается в том, что как setValue, так и setOtherValue используют параметр i, и это сбивает с толку, который следует вызывать для set i в setBoth?

3. @Aram в принципе. @Monkey Допустим, вы были в своей IDE, и вы делаете myFoo.setBoth( , и это всплывает i и j для имен. На самом деле это не так очевидно, как если бы в нем было сказано value и otherValue .

4. Да, теперь это имеет смысл. Во всяком случае, меня научили использовать более длинные имена, если это означает добавление дополнительной информации. Тем не менее, если имя метода достаточно пояснительно, это не должно быть проблемой.

Ответ №3:

Мы используем полные слова для переменных, например, и TLA для методов, поэтому наши будут иметь:

 public void setPresenter(Presenter prs) {
    presenter=prs;
    }

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

Ответ №4:

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

Тем не менее, вы должны использовать разумное имя для параметров. Вот почему я предпочитаю использовать префиксы для параметров и локальных переменных:

 public void setPresenter(Presenter pPresenter) {
    presenter = pPresenter;   //pXxxx stands for 'parameter'
    Presenter tPresenter = pPresenter;  //tXxxx stands for 'temporary' or local
}

1. вы также добавляете логические значения с префиксом b и переменные-члены с m_ ? 😉

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

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

4. -1 за загрязнение области общедоступных документов и сферы внутреннего кода, что наносит ущерб как пользователям api, так и сопровождающим. IDE обычно предупреждают о большинстве типов неправильных назначений. Если какой-либо метод настолько длинный, что вы забываете, что это такое — рефакторинг 😉

5. Как это загрязняет область документов и вредит сопровождающим больше, чем использование других соглашений? По крайней мере, вы знаете, как предполагается использовать переменную. Если вы не используете никаких префиксов, вы причиняете больше вреда сопровождающим и, возможно, пользователям api, поскольку вы не поддерживаете, когда у них просто есть код.