On 4/12/2018 8:56 PM, David Smiley wrote:
It's happening to me too! I added a /** anything */ comment on these two methods and the warning went away. But we don't have rules about requiring comments on public methods (I thought)?
I thought the point of the javadoc check was to make sure that all public methods *do* have javadocs, unless they're overriding a method in a parent class/interface that already has javadoc. (IDEs will display the parent javadoc in those cases)
I find it frustrating when I'm using a public API in a library and it's not documented to show how it can be used. While it's true that good choices for all the class/method/parameter names can sometimes make the exposed API self-documenting, often the usage is just too complex for that, or has gotchas that require explanation.
Probably a good idea for all public fields to have javadoc as well, but I wouldn't expect that to be a requirement.If javadoc on "protected" items is published, then I think those should require javadoc too, so someone extending the class will know what those things do.
Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
