Как заставить членов команды комментировать использование плагина eclipse или что-то еще

Question

В настоящее время я работаю в новом проекте, и мне было трудно понять, так как комментариев нет. Интересно, можно ли заставить членов команды (включая меня) добавить больше комментариев. Я хотел бы автоматизировать этот ject в jenkins позже, если это возможно.

Answer 1

Вы можете запускать статические проверки кода и их соответствующие плагины eclipse для обеспечения соблюдения комментариев, выполняемых в коде.

См., Например, в CheckStyle может быть применен javadoc http://checkstyle.sourceforge.net/config_javadoc.html

Также checkstyle можно легко интегрировать с Дженкинсом.

Вы также можете использовать настройки компилятора eclipse java для проверки javadoc.

Перейти к настройкам-> java-> compiler-> javadoc для обеспечения ошибок и предупреждений. ошибки и предупреждения компилятора могут быть легко сообщается путем непрерывного построения

приветствий,

Saurav

Answer 2

Я могу только рекомендовать, чтобы быть очень, очень осторожны с этим. Конечно, вы можете использовать такие инструменты, как SONAR, Eclipse Settings и т. П. Для обеспечения соблюдения комментариев.

Buuuuuuuut:

1. Вы можете легко создавать комментарии (/ ш Eclipse) и -как вы, вероятно, ноу- генерируемой комментарий не использовать/полезный вообще.
2. Если вы добавите полезный комментарий, и он слишком полагается на фактическую реализацию, вы также должны его поддерживать. Всякий раз, когда изменяется код, вам необходимо проверить, соответствует ли комментарий. Это часто упускается из виду и создает больше путаницы, а затем вообще не имеет комментариев. Несмотря на то, что у вас было хорошее намерение в первую очередь.
3. «The Truth Lies In The Code» (tm): вы можете добиться хорошего понимания и простого обслуживания кода, очень сильно работая над ним. Это может помочь избежать каких-либо комментариев вообще. Это нелегко (и не всегда возможно), я признаю это.
4. По крайней мере, «публичный API» должен быть документирован. Это может быть эмпирическое правило, и оно кажется управляемым в большой базе кода.

Я бы предпочел потратить больше времени на то, чтобы иметь хороший понятный код вместо «принудительных комментариев». Вы можете добиться полной противоположности, соблюдая ее.

Использование настроек Sonar/Eclipse для обеспечения документирования публичного API имеет смысл для меня.

Answer 3

Это должно быть реализовано на уровне контроля источника, а не на уровне IDE.

Если вы используете Git, вы можете посмотреть в GIT крючки http://git-scm.com/docs/githooks

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