Як написати 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 лише в геттері.

Я знайшов спосіб зробити це за допомогою анотацій, які працюють у затемненні і навіть можуть бути зібрані під час виконання, чи буде це варіантом?
Сила Водолія

приватним учасникам потрібен javadoc?
cherit

Ім'я бла бла бла: найкращий приклад
Родріго Еспіноза

Відповіді:


75

Ви можете включити приватних членів під час створення Javadocs (за допомогою -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 відображає посилання як ... (drumroll) .... посилання .., яке потрібно буде натиснути, щоб побачити вміст. Я хочу мати можливість активувати завершення коду (або наведенням миші) отримати javadoc для властивості, коли я фактично переглядаю геттер ...

13
@Kenny - не моделюйте свої практики JavaDoc на основі зручності використання POV Eclipse. Зробіть це з POV, щоб отримати правильний (або достатньо хороший) вихід JavaDoc. IDE змінюються, а те, що може бути недостатнім сьогодні, може бути вирішено завтра (або ви можете насправді змінити IDE повністю.)
luis.espinal

1
@luis @linkозначає посилання, яке потрібно натиснути, щоб побачити фактичний javadoc. Це не проблема зручності використання Eclipse, це неправильне рішення для забезпечення простих у використанні javadocs.
NateS

4

Ломбок - дуже зручна бібліотека для таких завдань.

@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. Тоді це виглядає так:

/**
 * 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, тому відмовився.

Зверніть увагу, що речення не завжди може починатися з Т - це лише перша буква, яку слід вставити без капіталу / докапіталізувати під час вставки.


23
Копіювати / вставити - це зло ... і трудомістко. Ці кроки виглядають як багато роботи, і якщо javadoc зміниться, у вас буде 3 різні місця для оновлення. Я не думаю, що плагін це також виправдає ... принаймні, тоді плагін повинен, наприклад, вважати властивість javadoc головним, а потім перезаписувати геттери (і сетери). Що я хочу досягти, це написати javadoc в одному єдиному місці, а потім отримати як геттери, так і властивості javadocs приймати однаковий опис ...

Як правило, властивості змінюються не так часто. А операції копіювання та вставки за допомогою автозаповнення Eclipse займають менше 30 секунд після побудови властивості Javadoc.
MetroidFan2002,

4
Я не впевнений ... Введення цього типу схеми копіювання / вставки IMHO обов’язково призведе до невідповідностей. Я занадто мало вірю в те, що інші кухарі (або я сам) згодом редагуватимуть код. Крім того, принаймні, якщо у вас немає повного попереднього дизайну, властивості javadoc часто можуть змінюватися, принаймні на етапі експерименту / проектування. І javadoc буде кращою якістю, якщо він буде написаний, коли код буде свіжим на увазі ... Вибачте, якщо я

1
На жаль, але редагування властивостей обов’язково призведе до невідповідностей - як би ви не грали, Javadoc, як правило, падає на другий план, якщо це енергійно не підтримується якимось чином. Навіть якби був простий спосіб викрити javadoc властивостей, так само ймовірно, що сам javadoc властивості не буде оновлений. Це справді питання правил кодування команди тощо, і оглядів коду, подібних речей - удачі вам, це саме так я роблю, щоб я не забув.
MetroidFan2002,

@Metroid - якщо він енергійно не підтримується якимось чином - ну, його слід енергійно підтримувати, якщо він трактується як частина самого вихідного коду. І не трактуючи коментарі Javadoc (та їх еквівалент на інших мовах) як невід’ємну частину коду, хоча, на жаль, це звичайна практика, це корінь багатьох зла. Найгірший коментар - той, що застарів. У кращому випадку вони сповільнюють програмістів, щоб вони не захопили код (оскільки їм доводиться постійно перепроводити та приймати / відхиляти застарілий коментар.) У гіршому випадку вони дають інформацію про помилки, що вводить помилки.
luis.espinal

0

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

Але я здогадуюсь: якщо вам потрібно пояснити, що таке someString, можливо, це `` поганий малий '' щодо вашого коду. Це може означати, що вам слід написати SomeClass, щоб набрати someString, щоб ви пояснили, що таке someString у документації SomeClass, і саме тому javadocs у getter / setter не буде необхідним.


1
Щодо неналежного використання рядків у коді, поставте прапорець `` Уникати рядків там, де інші типи більше підходять '' у книзі "Ефективна Java".
Леонардо Лейте
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.