Menu
Is there an annotation to declare that a certain method will not be included in the JavaDocs even though it is public?
Something like:
@nojavadocs
public void foo(){
//...
}
P.S. I understand the point here about API, but the methods are simply "unsupported." They work (and must be public for access from other packages), but we do not want to bother documenting them and answering questions about how to use them when their functionality is not relevant to supported usage scenarios. Good design might mean moving them to another class, but they logically refer to the data in the class.
874
{@code} is a Javadoc tag that came with Java 5. A code snippet embedded within {@code} will display our special characters correctly so they don't need to be manually escaped. However, indentation and line breaks will be lost. This can be rectified by using {@code} together with <pre> , though (see next section).
Writing Javadoc Comments In general, Javadoc comments are any multi-line comments (" /** ... */ ") that are placed before class, field, or method declarations. They must begin with a slash and two stars, and they can include special tags to describe characteristics like method parameters or return values.
As specified at Documentation Comment Specification for the Standard Doclet, Javadocs are recognized only when placed immediately before module, package, class, interface, constructor, method, or field declarations.
If an annotation precedes any of the definitions listed above, then the javadoc comment should be placed before the annotation.
The only reason I could think of that you'd want to do this would be to "hide" the method in some sense, if only in terms of documentation. If you did that you'd be designing the documentation to be "broken" in the sense that documentation becomes broken when it goes out of date and no longer accurately reflects what the class does. Since the method is still part of the public API you're not really hiding it anyway.
If you want a method to be unused outside of the class or a few users, make it private, or package. If this is inconvenient and it must be public, I'd just document very clearly the limitations on its use, possibly with a naming convention (for example, python does this, there are entity names surrounded by underscores, that you can see but are meant to be more part of the class implementation than the public api)
176
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
