java-docs
Javadoc best practices for documenting Java types, methods, and members.
- Public and protected members require Javadoc comments; package-private and private members are encouraged, especially for complex code
- Use standard tags:
@paramfor parameters,@returnfor return values,@throwsfor exceptions,@seefor cross-references, and@sincefor version tracking - First sentence serves as summary description and should end with a period; parameter descriptions start lowercase without periods
- Use
{@inheritDoc}to inherit documentation from base classes unless behavior changes significantly, and{@code}or<pre>{@code}</pre>for inline and block code snippets
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
@paramfor method parameters. The description starts with a lowercase letter and does not end with a period. - Use
@returnfor method return values. - Use
@throwsor@exceptionto document exceptions thrown by methods. - Use
@seefor references to other types or members. - Use
{@inheritDoc}to inherit documentation from base classes or interfaces.- Unless there is major behavior change, in which case you should document the differences.
- Use
@param <T>for type parameters in generic types or methods. - Use
{@code}for inline code snippets. - Use
<pre>{@code ... }</pre>for code blocks. - Use
@sinceto indicate when the feature was introduced (e.g., version number). - Use
@versionto specify the version of the member. - Use
@authorto specify the author of the code. - Use
@deprecatedto mark a member as deprecated and provide an alternative.
More from github/awesome-copilot
git-commit
Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
30.2Kgh-cli
GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line.
21.2Kdocumentation-writer
Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.
17.4Kprd
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.
17.4Kexcalidraw-diagram-generator
Generate Excalidraw diagrams from natural language descriptions. Use when asked to "create a diagram", "make a flowchart", "visualize a process", "draw a system architecture", "create a mind map", or "generate an Excalidraw file". Supports flowcharts, relationship diagrams, mind maps, and system architecture diagrams. Outputs .excalidraw JSON files that can be opened directly in Excalidraw.
16.4Krefactor
Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.
16.1K