Skip to main content
added 610 characters in body
Source Link
Thomas Owens
  • 85.9k
  • 18
  • 211
  • 311

JavaDoc already supports the inheriting of comments. According to the documentation, "constructors, fields and nested classes do not inherit doc comments", but methods such as equals() will. Since the Object class has a well-documented equals() method, you should just be able to inherit that documentation without a problem.

Depending onThe documentation for the toolmethod needs to come from somewhere so that you are usingit is accessible in your IDE and in the generated web documentation. Explicitly rewriting accurate and comprehensive comments that exist in a superclass is not necessary, and I would argue clutters the code files.

If this is corporate policy, then you have two options. You can go along with it should be trivial to findsliently, and viewdeal with the JavaDoc forextra effort of writing and maintaining documentation (often in violation of the methodDRY principle, regardlesswhich can also be applied to documents as well as code). The other option would be to seek company policy - explain why this policy isn't a good idea and the benefits of wherechanging it comes from(in terms of time, money, effort, quality - things that management understands).

JavaDoc already supports the inheriting of comments. According to the documentation, "constructors, fields and nested classes do not inherit doc comments", but methods such as equals() will. Since the Object class has a well-documented equals() method, you should just be able to inherit that documentation without a problem.

Depending on the tool that you are using, it should be trivial to find and view the JavaDoc for the method, regardless of where it comes from.

JavaDoc already supports the inheriting of comments. According to the documentation, "constructors, fields and nested classes do not inherit doc comments", but methods such as equals() will. Since the Object class has a well-documented equals() method, you should just be able to inherit that documentation without a problem.

The documentation for the method needs to come from somewhere so that it is accessible in your IDE and in the generated web documentation. Explicitly rewriting accurate and comprehensive comments that exist in a superclass is not necessary, and I would argue clutters the code files.

If this is corporate policy, then you have two options. You can go along with it sliently, and deal with the extra effort of writing and maintaining documentation (often in violation of the DRY principle, which can also be applied to documents as well as code). The other option would be to seek company policy - explain why this policy isn't a good idea and the benefits of changing it (in terms of time, money, effort, quality - things that management understands).

Source Link
Thomas Owens
  • 85.9k
  • 18
  • 211
  • 311

JavaDoc already supports the inheriting of comments. According to the documentation, "constructors, fields and nested classes do not inherit doc comments", but methods such as equals() will. Since the Object class has a well-documented equals() method, you should just be able to inherit that documentation without a problem.

Depending on the tool that you are using, it should be trivial to find and view the JavaDoc for the method, regardless of where it comes from.