Javadoc @author tag хорошие практики

Я бы сказал, что для большинства целей @author - это нежелательный шум. Пользователь вашего API не должен - и, вероятно, не-заботиться или хочет знать, кто написал какие части.

и, как вы уже заявили, SVN уже содержит эту информацию гораздо более авторитетным образом, чем может код. Поэтому, если бы я был одним из команды, я бы всегда предпочел журнал SVN и игнорировал @author. Держу пари, что код выйдет из синхронизации с реальностью, какую бы политику вы ни приняли. Следующий принцип "не повторяйся": зачем хранить эту информацию в двух местах?

Если, однако, есть какая-то бюрократическая или политическая причина, по которой эта информация должна быть включена в код, рассматривали ли вы автоматическое обновление @author тег в коде при регистрации? Ты мог бы!--11-->наверное достигните этого с крюком SVN. Вы можете, например, перечислить всех разработчиков, которые изменили данный файл в том порядке, в котором они его изменили; или кто изменил его больше всего; или что угодно. Или, если @author является обязательным в (исходном) коде, который вы выпускаете во внешний мир, вы можете рассмотреть возможность добавления @author автоматически как часть сборки выпуска (я подозреваю, что вы могли бы получить эту информацию из SVN каким-то образом).

что касается добавления более одного уровня класса @author tag (или другой комментарий), Я бы сказал, что вы будете накапливать много бесполезного шума. (Опять же, у вас есть SVN.)

по моему опыту гораздо полезнее определить историческое изменение (скажем, измените на строку кода или метод), затем, чтобы выяснить, к какому набору изменений это относится (и какой билет трека). Затем у вас есть полный контекст для изменения: у вас есть билет, набор изменений, вы можете найти другие наборы изменений в том же билете или примерно в то же время вы можете найти связанные билеты, и вы можете увидеть все изменения, которые сформировали эту единицу работы. Вы никогда не получите это из аннотации или комментариев в коде.