Parent issue: #19807
Coverage table
Writing Programming Guide Documentation
Chapter link
Content
Image
Text
Writing Programming Guide Documentation
What separates API specifications from a programming guide are examples, definitions of common programming terms, certain conceptual overviews (such as metaphors), and descriptions of implementation bugs and workarounds. There is no dispute that these contribute to a developer's understanding and help a developer write reliable applications more quickly. However, because these do not contain API "assertions", they are not necessary in an API specification. You can include any or all of this information in documentation comments (and can include custom tags, handled by a custom doclet, to facilitate it). At Java Software, we consciously do not include this level of documentation in doc comments, and instead include either links to this information (links to the Java Tutorial and list of changes) or include this information in the same documentation download bundle as the API spec -- the JDK documentation bundle includes the API specs as well as demos, examples, and programming guides.
It's useful to go into further detail about how to document bugs and workarounds. There is sometimes a discrepancy between how code should work and how it actually works. This can take two different forms: API spec bugs and code bugs. It's useful to decide up front whether you want to document these in the doc comments. At Java Software we have decided to document both of these outside of doc comments, though we do make exceptions.
API spec bugs are bugs that are present in the method declaration or in the doc comment that affects the syntax or semantics. An example of such a spec bug is a method that is specified to throw a NullPointerException when null is passed in, but null is actually a useful parameter that should be accepted (and was even implemented that way). If a decision is made to correct the API specification, it would be useful to state that either in the API specification itself, or in a list of changes to the spec, or both. Documenting an API difference like this in a doc comment, along with its workaround, alerts a developer to the change where they are most likely to see it. Note that an API specification with this correction would still maintain its implementation-independence.
Code bugs are bugs in the implementation rather than in the API specification. Code bugs and their workarounds are often likewise distributed separately in a bug report. However, if the Javadoc tool is being used to generate documentation for a particular implementation, it would be quite useful to include this information in the doc comments, suitably separated as a note or by a custom tag (say @bug).
Guidelines
This chapter does not appear to contain any guidelines. My proposal is to represent this part of the document in the coverage table with rows such as the following:
| Documentation Comments Rule |
Checkstyle Checks Used |
Sample files |
| Writing Programming Guide Documentation |
-- |
|
| API spec bugs |
-- |
|
| Code bugs |
-- |
|
Parent issue: #19807
Coverage table
Writing Programming Guide Documentation
Chapter link
Content
Image
Text
Writing Programming Guide Documentation
What separates API specifications from a programming guide are examples, definitions of common programming terms, certain conceptual overviews (such as metaphors), and descriptions of implementation bugs and workarounds. There is no dispute that these contribute to a developer's understanding and help a developer write reliable applications more quickly. However, because these do not contain API "assertions", they are not necessary in an API specification. You can include any or all of this information in documentation comments (and can include custom tags, handled by a custom doclet, to facilitate it). At Java Software, we consciously do not include this level of documentation in doc comments, and instead include either links to this information (links to the Java Tutorial and list of changes) or include this information in the same documentation download bundle as the API spec -- the JDK documentation bundle includes the API specs as well as demos, examples, and programming guides.
It's useful to go into further detail about how to document bugs and workarounds. There is sometimes a discrepancy between how code should work and how it actually works. This can take two different forms: API spec bugs and code bugs. It's useful to decide up front whether you want to document these in the doc comments. At Java Software we have decided to document both of these outside of doc comments, though we do make exceptions.
API spec bugs are bugs that are present in the method declaration or in the doc comment that affects the syntax or semantics. An example of such a spec bug is a method that is specified to throw a NullPointerException when null is passed in, but null is actually a useful parameter that should be accepted (and was even implemented that way). If a decision is made to correct the API specification, it would be useful to state that either in the API specification itself, or in a list of changes to the spec, or both. Documenting an API difference like this in a doc comment, along with its workaround, alerts a developer to the change where they are most likely to see it. Note that an API specification with this correction would still maintain its implementation-independence.
Code bugs are bugs in the implementation rather than in the API specification. Code bugs and their workarounds are often likewise distributed separately in a bug report. However, if the Javadoc tool is being used to generate documentation for a particular implementation, it would be quite useful to include this information in the doc comments, suitably separated as a note or by a custom tag (say @bug).
Guidelines
This chapter does not appear to contain any guidelines. My proposal is to represent this part of the document in the coverage table with rows such as the following: