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

Question

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

Answer 1

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

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

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

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

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

веселит,

Saurav

Answer 2

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

Если вы используете git, вы можете посмотреть на git hooks http://git-scm.com/docs/githooks

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

Answer 3

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

Buuuuuuuut:

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

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

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