Лучшие практики для именования параметров в Java-конструкторах и простых установщиках - PullRequest
Новая
       13

Лучшие практики для именования параметров в Java-конструкторах и простых установщиках

40 голосов
/ 14 июня 2009

Существует ли стандартное приемлемое соглашение для параметров в Java для простых конструкторов и сеттеров?

( Я видел ответ для C ++ , но методы часто различаются между двумя сообществами)

Предположим, у меня есть класс C с полем foo.

Я обычно видел следующие три варианта:

1) Используйте фактическое имя поля с подчеркиванием: 

public C(Type foo_)
{
   foo = foo_;
}

public void setFoo(Type foo_)
{
   foo = foo_;
}

2) Используйте фактическое имя поля, просто используйте «this» в настройках: 

public C(Type foo)
{
   this.foo = foo;
}
public void setFoo(Type foo)
{
   this.foo = foo;
}

3) Совершенно противоречивые вещи, такие как: 

public C(Type bar)
{
   this.foo = bar;
}
public void setFoo(Type bar)
{
   this.foo = bar;
}

Я склонен использовать 2, но мне интересно, что такое правильная практика.

Ответы [ 13 ]

49 голосов
/ 14 июня 2009

Вариант второй является наиболее распространенным. В Java считается плохой практикой использовать бессмысленные префиксы или суффиксы имен, чтобы отличать переменные экземпляра от параметров от локальных переменных. Но нет никаких соглашений для самих имен. Используйте любые имена, чтобы сделать код проще для понимания.

19 голосов
/ 14 июня 2009

Я также видел вариант 2 как наиболее распространенный: 

int importance;

public int getImportance()
{
    return importance;
}

public void setFoo(int importance)
{
    this.importance = importance;
}

Среды разработки, такие как Eclipse и Netbeans, будут автоматически записывать методы получения и установки в указанном выше формате.

Есть несколько преимуществ использования этого метода:

Не использует символ подчеркивания (_) в имени поля - подчеркивания не рекомендуются для непостоянных имен полей.

Использование символа подчеркивания в идентификаторе не рекомендуется, за исключением идентификаторов для констант.

На странице Переменные в Учебниках Java упоминается следующее о подчеркивании:

Если ваша переменная хранит константу значение, например static final int NUM_GEARS = 6, соглашение меняется немного заглавными буквами и разделяя последующие слова символ подчеркивания. По условный знак подчеркивания никогда не используется в другом месте.

(выделение добавлено.)

Поскольку имена полей не являются константами, в соответствии с тем, что написано на этой странице, не следует использовать подчеркивания в непостоянных полях.

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

Ниже приведен пример автоматически сгенерированного Javadoc: 

/**
 *
 * @param importance  <-- Parameter name in Javadoc matches
 *                        the parameter name in the code.
 */
public void setImportance(int importance)
{
    this.importance = importance;
}

Наличие в Javadoc имени поля имеет еще одно преимущество - В средах IDE, для которых выполняется завершение кода, можно использовать имя поля в Javadoc для автоматического заполнения имен параметров: 

// Code completion gives the following:
this.getImportance(importance);

Придание значения имени поля и имени параметра облегчит понимание того, что на самом деле представляет параметр.

Вот некоторые из достоинств, которые я могу придумать в данный момент, и я считаю, что это, скорее всего, самый распространенный способ именования параметров в Java.

9 голосов
/ 14 июня 2009

(1) очень C / C ++. Java не склонна часто использовать символы подчеркивания.

Лично я использую (2) почти исключительно.

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

3 голосов
/ 14 июня 2009

Я знаю, что когда netbeans автоматически создает методы получения и установки, он использует метод номер 2. Лично я обычно добавляю temp к переменной, т.е. foo = tempfoo. Но, как говорит Ниш, вы должны стараться быть последовательными независимо от того, какой метод вы выберете

3 голосов
/ 14 июня 2009

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

Генерация кода Eclipse использует стиль # 2 из вашего списка.

1 голос
/ 27 июня 2016

Я лично использую foo(Bar parBar), хотя я знаю, что обычно считается плохой практикой предварительно или суффиксировать имена переменных.

Причина этого довольно проста: Ясность

Теперь, если вы вызываете метод foo(Bar bar), он не всегда может быть интуитивно понятным, что bar означает на самом деле . И даже если это так, это все еще боль в заднице.

Как this.bar = bar или даже bar = bar чище и интуитивно понятнее, чем bar = parBar? У меня скорее префикс, чем логическая неоднозначность.

1 голос
/ 08 апреля 2015

Вариант 2 - это то, что рекомендуют большинство руководств по стилю Java.

Я нашел руководство по стилю Google Java довольно полезным:

обновленная ссылка (июнь-2019): https://google.github.io/styleguide/javaguide.html

или поищите в Интернете «Руководство по стилю Google Java»

1 голос
/ 16 января 2014

Да, вариант 2 наиболее широко используется; хотя это имеет серьезную проблему: если в объявлении вашего параметра есть опечатка - это может остаться незамеченным из-за shadowing , например: 

class Whatever { 
  String val;
  Whatever(String va1) { this.val = val; }
  void printMe() { System.out.println(val.toString()); }
  public static void main(String[] args) {
    new Whatever("Hello").printMe();
  }
}

Этот код прекрасно компилируется; и вам понадобится секунда, чтобы понять, что там не так. Если вы сомневаетесь; просто распечатайте это; отнесите его своим коллегам и спросите, что произойдет, если этот класс будет скомпилирован и выполнен. Мое предположение: 75% + не поймут, что будет выдано исключение NullPointerException. И если вы обращаетесь к шрифту, который «выглядит одинаково» для val и va1; тогда никто не заметит прочтения ...

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

Но: если вы избегаете этого паттерна и используете префиксы или "thatString", вы никогда не столкнетесь с этой проблемой в первую очередь. Таким образом, я действительно не понимаю, почему это так часто используется.

Итак, мы сели в нашу команду и, составляя наше руководство по стилю кодирования, мы сказали: никогда не используйте вариант 2.

0 голосов
/ 05 апреля 2019

Хотя возвращение void из установщика является обычным делом, иногда удобно возвращать ссылку на экземпляр: 

public class Foo {

    String value1, value2;

    public Foo setValue1(String value1) {
        this.value1 = value1;
        return this;
    }

    public Foo setValue2(String value2) {
        this.value2 = value2;
        return this;
    }
}

Это позволяет вам связать настройки значений: new Foo().setValue1("A").setValue2("B");

0 голосов
/ 15 мая 2013

Вариант 2 наиболее распространен в Java, но требовательный Checkstyle не позволит вам использовать эту опцию, потому что имя локальной переменной затеняет другой.

Из-за этого большинство используют следующее:

foo(int thatBar) { this.bar = thatBar; }

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

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

Страница:
...