Skillshub java-docs
Ensure that Java types are documented with Javadoc comments and follow best practices for documentation.
install
source · Clone the upstream repo
git clone https://github.com/ComeOnOliver/skillshub
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/ComeOnOliver/skillshub "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/github/awesome-copilot/java-docs" ~/.claude/skills/comeonoliver-skillshub-java-docs && rm -rf "$T"
manifest:
skills/github/awesome-copilot/java-docs/SKILL.mdsource content
Java Documentation (Javadoc) Best Practices
- Public and protected members should be documented with Javadoc comments.
- It is encouraged to document package-private and private members as well, especially if they are complex or not self-explanatory.
- The first sentence of the Javadoc comment is the summary description. It should be a concise overview of what the method does and end with a period.
- Use
for method parameters. The description starts with a lowercase letter and does not end with a period.@param - Use
for method return values.@return - Use
or@throws
to document exceptions thrown by methods.@exception - Use
for references to other types or members.@see - Use
to inherit documentation from base classes or interfaces.{@inheritDoc}- Unless there is major behavior change, in which case you should document the differences.
- Use
for type parameters in generic types or methods.@param <T> - Use
for inline code snippets.{@code} - Use
for code blocks.<pre>{@code ... }</pre> - Use
to indicate when the feature was introduced (e.g., version number).@since - Use
to specify the version of the member.@version - Use
to specify the author of the code.@author - Use
to mark a member as deprecated and provide an alternative.@deprecated