Как написать Javadoc свойств?

93

Я часто сталкиваюсь с дилеммой при написании javadoc для свойств / членов "простого" класса POJO, содержащего только свойства, геттеры и сеттеры (стиль DTO) ....

1) Напишите javadoc для свойства
или ...
2) Напишите javadoc для получателя

Если я напишу javadoc для свойства, моя IDE (Eclipse) (естественно) не сможет отобразить это, когда я позже получу доступ к POJO через завершение кода. И нет стандартного тега javadoc, который позволяет мне связать getter-javadoc с фактическим свойством javadoc.

Пример:

public class SomeDomainClass {

  /**
   * The name of bla bla bla
   */
  private String name;

  /**
   * @return INSERT SOME SMART JAVADOC TAG LINKING TO name's javadoc
   */
  public String getName() {  
    return name;  
  }  

Итак, в основном было бы интересно услышать, как другие делают так, чтобы ваша Eclipse IDE отображала описание свойства javadoc для ваших получателей - без необходимости дублировать комментарий javadoc.

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


источник
1
Интересное обсуждение здесь: stackoverflow.com/questions/1028967/… . Принятый ответ касается того, что вы спросили об Eclipse / javadoc.
b.roth
Похоже, они пришли к выводу, что я думал ... писать javadoc свойств только в геттерах.
Я нашел способ сделать это с помощью аннотаций, которые работают в eclipse и даже могут быть собраны во время выполнения, будет ли это вариант?
Сила Водолея
частным членам нужен javadoc?
teon
Имя бла-бла-бла: лучший пример
Родриго Эспиноза

Ответы:

76

Вы можете включить частные члены при создании документации Javadoc (используя -private), а затем использовать @link для ссылки на это свойство полей.

public class SomeDomainClass {
    /**
     * The name of bla bla bla
     */
    private String name;

    /**
     * {@link SomeDomainClass#name}
     */
    public String getName() {
        return name;
    }
}

В качестве альтернативы, если вы не хотите создавать Javadoc для всех частных членов, вы можете иметь соглашение о документировании всех получателей и использовать @link для установщиков.

public class SomeDomainClass {
    private String name;

    /**
     * The name of bla bla bla
     */
    public String getName() {
        return name;
    }

    /**
     * {@link SomeDomainClass#getName}
     */
    public void setName(String name) {
        this.name = name;
    }
}
Чандра Секар
источник
2
Я экспериментировал с тегами @link и @see ... Но ... по крайней мере, Eclipse не отображает это должным образом. Eclipse отображает ссылку как ... (барабанная дробь) .... ссылка .. которую нужно будет щелкнуть, чтобы увидеть содержимое. Я хочу иметь возможность активировать завершение кода (или при наведении указателя мыши) получить javadoc для свойства, когда я на самом деле просматриваю получатель ...
13
@Kenny - не моделируйте свои практики JavaDoc с точки зрения удобства использования Eclipse. Сделайте это с точки зрения получения правильного (или достаточно хорошего) вывода JavaDoc. IDE меняются, и то, что сегодня может быть несовершенным, может быть исправлено завтра (или вы можете полностью изменить IDE)
luis.espinal
1
@luis @linkозначает ссылку, по которой нужно щелкнуть, чтобы увидеть фактическую javadoc. Это не проблема удобства использования Eclipse, это неправильное решение для предоставления простой в использовании документации javadoc.
NateS
4

Lombok - очень удобная библиотека для таких задач.

@Getter
@Setter
public class Example {
    /**
     * The account identifier (i.e. phone number, user name or email) to be identified for the account you're
     * requesting the name for
     */
    private String name;
}

Это все, что вам нужно! @GetterАннотацию создает геттер для каждого частного поля и прикрепить Javadoc к нему.

PS : В библиотеке есть много интересных функций, которые вы, возможно, захотите проверить

Амануэль Нега
источник
3

Я делаю и то, и другое, чему способствует автозаполнение Eclipse.

Сначала я документирую недвижимость:

/**
 * The {@link String} instance representing something.
 */
private String someString;

Затем я копирую и вставляю это в геттер:

/**
 * The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

В eclipse операторы @return имеют автозаполнение - поэтому я добавляю слово Gets, строчную букву «t» и копирую предложение со строчной буквой «t». Затем я использую @return (с автозаполнением Eclipse), вставляю предложение, а затем заглавную букву T в return. Тогда это выглядит так:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

Наконец, я копирую эту документацию в установщик:

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

Затем я модифицирую его, и с помощью автозаполнения Eclipse вы можете получить не только тег @param, но и имя параметра:

/**
 * Sets the {@link String} instance representing something.
 * @param someString The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

Тогда я закончил. На мой взгляд, этот шаблон значительно упрощает, в конечном итоге, не только напоминать себе, что означает свойство посредством повторения, но также упрощает добавление дополнительных комментариев к геттеру и сеттеру, если вы хотите добавить сторону эффекты (например, запрет на использование пустых свойств, перевод строк в верхний регистр и т. д.). Я исследовал создание плагина Eclipse для этой цели, но не смог найти подходящую точку расширения для JDT, поэтому сдался.

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

MetroidFan2002
источник
24
Копирование / вставка - это зло ... и отнимает много времени. Эти шаги выглядят как большая работа, и если javadoc изменится, у вас будет 3 разных места для обновления. Я не думаю, что плагин оправдал бы это ... по крайней мере, тогда плагин должен был бы, например, рассматривать свойство javadoc как мастер, а затем перезаписывать геттеры (и сеттеры). Я хочу написать javadoc в одном месте, а затем заставить и getters, и property javadocs принять одно и то же описание ...
Обычно свойства меняются не так часто. А операции копирования и вставки с автозаполнением Eclipse занимают менее 30 секунд после создания Javadoc свойства.
MetroidFan2002,
4
Я не уверен ... Введение этого типа схемы копирования / вставки IMHO неизбежно приведет к несоответствиям. Я слишком мало верю в то, что другие повара (или я) позже отредактируют код. Кроме того, по крайней мере, если у вас нет полного предварительного проектирования, свойства javadoc часто могут изменяться, по крайней мере, на этапе экспериментов / проектирования. И javadoc будет более качественным, если будет написан, когда код свеж в памяти ... Извините, если я
1
Извините, но редактирование свойств неизбежно приведет к несоответствиям - в любом случае, Javadoc имеет тенденцию уходить на второй план, если он не поддерживается каким-либо образом. Даже если бы существовал простой способ раскрыть свойство javadoc, вполне вероятно, что само свойство javadoc не будет обновлено. На самом деле это вопрос соглашений о кодировании в команде и т. Д., И обзоров кода и тому подобного - удачи вам, я просто так делаю, поэтому не забываю.
MetroidFan2002
@Metroid - если он не поддерживается каким-либо образом - что ж , предполагается, что он будет активно поддерживаться, если рассматривается как часть самого исходного кода. И не рассматривать комментарии Javadoc (и их эквиваленты на других языках) как неотъемлемую часть кода, хотя, к сожалению, это стандартная практика, но это корень многих зол. Худший комментарий - тот, который устарел. В лучшем случае они мешают программистам разобраться в коде (поскольку им приходится постоянно проверять и принимать / отклонять устаревшие комментарии). В худшем случае они предоставляют подверженную ошибкам информацию, содержащую ошибки.
luis.espinal 09
0

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

Но у меня есть предположение: если вам нужно объяснить, что такое someString, возможно, это `` плохая мелочь '' в вашем коде. Это может означать, что вы должны написать SomeClass для ввода someString, чтобы вы объяснили, что такое someString в документации SomeClass, и просто чтобы javadocs в getter / setter не понадобились.

Леонардо Лейте
источник
1
Что касается неправильного использования строк в коде, проверьте «Избегайте строк там, где другие типы более подходят» в книге «Эффективная Java».
Леонардо Лейте