121

Is it correct practice to add Javadoc comments in the interface and add non-Javadoc comments in the implementation?

Most IDEs generate non-JavaDoc comments for implementations when you auto generate comments. Shouldn't the concrete method have the description?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Vaishak Suresh
  • 5,735
  • 10
  • 41
  • 66

7 Answers7

78

For methods that are implementation only (not overrides), sure, why not, especially if they are public.

If you have an overriding situation and you are going to replicate any text, then definitely not. Replication is a surefire way of causing discrepancies. As a result, users would have a different understanding of your method based on whether they examine the method in the supertype or the subtype. Use @inheritDoc or don't provide a documentation - The IDEs will take the lowest available text to use in their Javadoc view.

As an aside, if your overriding version adds stuff to the documentation of the supertype, you could be in a world of trouble. I studied this problem during my PhD and found that in general folks will never be aware of the extra information in the overriding version if they are invoking through a supertype.

Addressing this problem was one of the major feature of the prototype tool that I built - Whenever you invoked a method, you got an indication if its target or any potential overriding targets contained important information (e.g., a conflicting behavior). For instance, when invoking put on a map, you were reminded that if your implementation is a TreeMap, your elements need to be comparable.

Community
  • 1
  • 1
Uri
  • 88,451
  • 51
  • 221
  • 321
  • 1
    Don't you already know that elements need to be compareable when using a TreeMap? An implementation also shouldn't implement conflicting behaviour. – Jimmy T. May 16 '16 at 11:26
  • 1
    I think this should be the correct answer http://stackoverflow.com/a/39981265/419516 – user219882 Oct 12 '16 at 08:15
31

Both the implementation and the interface should have javadoc. With some tools, you can inherit the documentation of the interface with the @inheritDoc keyword.

/**
 * @inheritDoc
 *
 * This implementation is very slow when b equals 3.
 */
public foo(int b)
{ ... }
Sjoerd
  • 74,049
  • 16
  • 131
  • 175
  • 6
    What exactly are 'some tools'? Does it work out of the box or is it bound to some specific plugins. – jediz Dec 05 '14 at 10:30
  • I know Eclipse uses `{@inheritDoc}` and it only works if you _don't_ have the annotation `@Override` first – ksnortum Oct 19 '15 at 02:43
26

Somewhat good practice is to put

/**
 * {@inheritDoc}
 */

as implementation's javadoc (unless there's something extra to be explained about the implementation's details).

Vanya
  • 3,091
  • 2
  • 18
  • 12
  • 2
    The point of having an interface is that the method can be implemented in multiple ways. If I am just going to inherit the comments, what is the point in having the comment in the implementation? – Vaishak Suresh Jun 17 '10 at 12:17
  • 16
    I use the above tag and then put any extra required documentation below the tag. – Ben Page Jun 15 '11 at 12:15
21

Generally, when you override a method, you adhere to the contract defined in the base class/interface, so you don't want to change the original javadoc anyhow. Therefore the usage of @inheritDoc or @see tag mentioned in other answers is not needed and actually only serves as a noise in the code. All sensible tools inherit method javadoc from the superclass or interface as specified here:

Inherit from classes and interfaces - Inheriting of comments occurs in all
three possible cases of inheritance from classes and interfaces:

- When a method in a class overrides a method in a superclass
- When a method in an interface overrides a method in a superinterface
- When a method in a class implements a method in an interface

The fact that some tools (I'm looking at you, Eclipse!) generate these by default when overriding a method is only a sad state of things, but doesn't justify cluttering your code with useless noise.


There can of course be the opposite case, when you actually want to add a comment to the overriding method (usually some additional implementation details or making the contract a bit stricter). But in this case, you almost never want to do something like this:

/**
 * {@inheritDoc}
 *
 * This implementation is very, very slow when b equals 3.
 */

Why? Because the inherited comment can possibly be very long. In such case, who will notice the extra sentence at the end of the 3 long paragraphs?? Instead, just write down the piece of your own comment and that's all. All the javadoc tools always show some kind of Specified by link which you can click to read the base class comment. There is no point in mixing them.

Natix
  • 14,017
  • 7
  • 54
  • 69
6

@see It generates a link to the description in the interface. But I think it is good to add some details about the implementation too.

TuGordoBello
  • 4,350
  • 9
  • 52
  • 78
redben
  • 5,578
  • 5
  • 47
  • 63
  • 6
    IMO using `@see` linking to interface methods is a good practice and it is enough in most cases. When you copy javadoc from interface method to concrete implementation you just duplicate information and it can quickly become inconsistent. However, any additional information about the implementation should be added to javadoc. – Piotr Jun 17 '10 at 12:04
  • 1
    The additional doc is not about copying the doc from the interface, but just to explain how you implement the method and stuff like that. With an interface doc, your explain what the results/objectives (application state or method return) whereas in your implementation it might be good to explain how you achieve this objectives. – redben Jun 19 '10 at 21:52
5

Sjoerd correctly says that both interface and implementation should have JavaDoc. The interface JavaDoc should define the contract of the method - what the method should do, what inputs it takes, what values it should return, and what it should do in cases of error.

The implementation documentation should note extensions or restrictions on the contract, and also appropriate details of the implementation, especially performance.

DJClayworth
  • 26,349
  • 9
  • 53
  • 79
0

For the sake of generated javadoc yes it does matter. If you declare references to a concrete implementation using only the interface then it doesn't since interface's methods will be retrieved by the IDE.

Boris Pavlović
  • 63,078
  • 28
  • 122
  • 148