Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Javadoc @author tag good practices

I'm wondering about best practices when creating Javadocs. I have a project with many files. Code has been created by many developers. Each file has an annotation @author, so it is obvious who has created a particular class.

But when some other developer adds new code to a file, modifies it, etc., how should he inform the rest of the team that he has created some new function or has modified existing code? In other words, how should we "keep the Javadocs compatible with reality"? ;)

  • Add his name to the existing @author tag? Then, it is easier to identify who to ask in case of any doubts.
  • Add an @author tag to each new method, inner class, etc.?

Of course, since we use SVN, it is easy to investigate who has made what, but for keeping things clear this Javadoc stuff should be taken into consideration as well.

What's the best way to use these @author tags?

like image 753
guitar_freak Avatar asked Jun 24 '13 07:06

guitar_freak


People also ask

Are @author tags required by Javadoc?

The tag is not actually included in generated Javadoc. At least not by default - you need to explicitly specify -author parameter to include the information in the generated documentation. Therefore it is only visible to a person, who is viewing the source code.

What should be included in a Javadoc?

Before using JavaDoc tool, you must include JavaDoc comments /**……………….. */ providing information about classes, methods, and constructors, etc. For creating a good and understandable document API for any java file you must write better comments for every class, method, constructor.


2 Answers

I would say that for most purposes @author is unwanted noise. The user of your API shouldn't - and probably doesn't - care, or want to know, who wrote which parts.

And, as you have already stated, SVN already holds this information in a much more authoritative way than the code can. So if I was one of the team, I would always prefer SVN's log and ignore the @author. I'd bet that the code will get out of sync with reality, whatever policy you adopted. Following the Don't Repeat Yourself principle, why hold this information in two places?

If, however, there is some bureaucratic or policy reason that this information MUST be included in the code, have you considered automatically updating the @author tag in the code on check in? You could probably achieve this with an SVN hook. You could for example list all the developers who changed a given file in the order they changed it; or who changed it most; or whatever. Or, if the @author is mandated in (source) code you release to the outside world, you could consider adding the @author automatically as part of the release build (I suspect you could get this information out of SVN somehow).

As for adding more than a single class level @author tag (or other comment), I'd say you'd be accumulating a lot of unhelpful noise. (Again, you have SVN.)

In my experience it is much more useful to identify a historical change (say a change to a line of code, or a method), then to work out which change set this relates to (and which track ticket). Then you have the full context for the change: you have the ticket, the change set, you can find other change sets on the same ticket, or around the same time, you can find related tickets, and you can see ALL the changes that formed that unit of work. You are never going to get this from annotation or comments in code.

like image 154
Paul Avatar answered Oct 09 '22 06:10

Paul


You may want to consider why you want author tags in the source. The Apache Foundation do not and I agree.

http://www.theinquirer.net/inquirer/news/1037207/apache-enforces-the-removal-of-author-tags

To my best understanding this is a cargo cult way of working from when sources were printed on paper. With modern version control systems this information and more can be found in the history anyway.

like image 37
Thorbjørn Ravn Andersen Avatar answered Oct 09 '22 07:10

Thorbjørn Ravn Andersen