Как автоматически генерировать комментарии для получателя / установщика, основываясь на полевых комментариях в Eclipse?

Question

Я хочу, чтобы Eclipse автоматически генерировал комментарии Javadoc для моих методов получения и установки на основе ранее определенных комментариев для полей. Как мне этого добиться?

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

Пример:

/**
 * name of the dynamic strategy
 */
private String dynName;

/**
 * get the name of the dynamic strategy
 * @return
 */
public String getDynName() {
    return dynName;
}

Поиск в сети показал, что я не единственная, кто столкнулся с проблемой, но я не смог найти никаких решений. Я проверил http://jautodoc.sourceforge.net/, но кажется, что он не способен сделать это.

Answer 1

JAutodoc начиная с версии 1.6 (1 год после вопроса) имеет новую опцию «[G, S] etter from field comment», которая делает именно то, что вы хотите.

Это довольно удобная функция. Комментарии к полям обычно не включаются в окончательный HTML-код Javadoc, поскольку они могут / должны быть частными участниками (создание Javadoc для каждого частного участника также не годится), поэтому без него комментарии будут полностью потеряны!

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

Answer 2

Я наконец нашел решение (или хотя бы обходной путь) сам. Я читал о ложка на SO. Это программный процессор Java, который позволяет читать и изменять исходные файлы Java. Его можно использовать даже как плагин Eclipse или скрипт Ant / Maven.

Все, что вам нужно сделать, это расширить AbstractProcessor, который будет обрабатывать метод. Если имя метода начинается с get / set, оно ищет соответствующее поле, извлекает его комментарий и заменяет или расширяет комментарий метода доступа.

У меня есть небольшой муравейный скрипт, который берет все мои источники и обрабатывает их.

Что-то, встроенное в шаблоны кода затмений, было бы, конечно, более удобным, но сейчас этот способ в порядке!

Answer 3

Я согласен, что дублирование документации является проблемой. А как насчет документирования закрытой переменной и затем предоставления ссылки на эту документацию в методах доступа?

(Очевидно, что следующее решение предназначено для очень простых методов доступа . Вы действительно не хотите показывать документацию по частным переменным в своем API, особенно если ваш метод доступа действительно делает что-то примечательное.)

public class MyBean {

/**
 * The names description
 */
private String name;

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

/**
 * @param name {@link #name}
 */
public void setName(String name) {
    this.name = name;
}
}

Обратите внимание, что если вы используете Eclipse, вам может потребоваться включить ссылку на частные переменные в вашем javadoc следующим образом:

Щелкните правой кнопкой мыши по проекту в Package Explorer и выберите Properties Сверните узел Java Compiler и выберите Javadoc Выберите включить специфичные для проекта настройки и под Рассматривать только участников как видимых: выбрать личное

Я подозреваю, что это повлияет на производительность поиска, но я еще не проверял, насколько.

Answer 4

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

Answer 5

Если бы у вас был макроязык, вы могли бы написать функцию типа «открыть всплывающее окно, которое позволяет мне набирать какой-то текст, а затем генерировать метод получения и установки, включая его javadoc, на основе шаблонов».

Eclipse на самом деле не имеет реальной поддержки такого макроязыка, но, возможно, вы могли бы в любом случае взглянуть на: Есть ли Macro Recorder для Eclipse?

Если вы не хотите переключаться между eclipse и другим инструментом, то вы можете попробовать JEdit (jedit.org), который включает мощный макроязык языка бобов. Таким образом, вы можете открыть eclipse & jedit, перетащить и отбросить файл, который вы хотите обработать, из eclipse в jedit, использовать макрос power jedit, затем сохранить файл и, наконец, обновить файл в eclipse.

Это немного раздражает, но для некоторых обработок это способ, которым я успешно освоил.

Answer 6

Я использую Eclipse Luna 4.4.

• Выберите меню Window \ Preferences, выберите Java \ Code Style \ Code Templates. Выберите раздел Comments \ Getters | Setters, нажмите кнопку Edit....
  
  

• Для вас существует множество переменных, используйте кнопку Insert Variable...
  
  

• Отредактируйте формат комментария, затем нажмите кнопку Apply, затем нажмите OK для завершения.

Answer 7

ИМХО Если комментарии могут генерироваться автоматически, они не приносят особой пользы.
Если вы вызвали свой метод getDynamicStrategyName (), вам не нужно комментировать его, так как имя содержит всю информацию, которую вы бы поместили в комментарии.

Answer 8

Плагин JavadocWriter для IntelliJ IDEA говорит, что он "умно копирует Javadoc из поля в средство доступа". Предостережение: я не пробовал сам плагин, и он не обновлялся 3 года.

Answer 9

На самом деле JAutodoc может генерировать комментарии для получателя / установщика на основе комментариев поля. Вы должны проверить опцию «Создать комментарий из имени элемента», см. http://jautodoc.sourceforge.net/ для документации.