Code Quality Tools Deep Dive · 6 of 6

Doc Generators — Reference Docs That Stay Honest

Documentation that lives in a wiki and lies the moment the code changes is worse than no docs. Doc generators read your source — types, comments, signatures — and produce a reference site that's regenerated on every build. Pair with tutorials and how-tos written by humans, and you get docs that scale: the API reference is always current, and the conceptual material gets the love it actually deserves.

JavadocJSDocSphinxTypeDocDocusaurusOpenAPI
← Back to Testing
Quick Facts

What Doc Generators Do

Basic Concepts

  • Source-of-truth in code. The doc generator extracts function signatures, types, and structured comments — and produces an API reference site or a man page.
  • Regenerated on build. Docs are an artifact; they're rebuilt every time the code is. Drift is impossible by construction for the parts the generator covers.
  • Reference, not tutorial. Generators are great at "what does foo() take and return." They're poor at "how do I use this system." Pair them with hand-written guides.
  • The Diátaxis model: docs split into tutorials, how-tos, reference, and explanation. Generators handle reference; humans write the rest.
Tools

By Stack

StackGeneratorNotes
JavaJavadocBuilt into the JDK. The original. Output: HTML reference site.
KotlinDokkaJavadoc for Kotlin; outputs HTML, Markdown, or Javadoc-compatible.
.NETDocFX, Sandcastle (legacy)DocFX builds API + conceptual docs from XML doc comments.
JavaScript / TypeScriptTypeDoc, JSDoc, API ExtractorTypeDoc is the modern default for TS. JSDoc still common for plain JS.
PythonSphinx, mkdocs, pdocSphinx is the heavyweight standard; mkdocs (with mkdocstrings) is friendlier; pdoc is minimalist.
RubyYARD, RDocYARD is the standard with rich tag support.
Gogo doc, pkg.go.devBuilt-in. Comments above public symbols are the docs.
RustrustdocStandard, runs doctests as part of the test suite.
C / C++DoxygenThe veteran. Cross-language; ugly default theme; widely deployed.
PHPphpDocumentorStandard generator from PHPDoc comments.
API specsOpenAPI / Redoc / Swagger UIGenerates browsable API docs from an OpenAPI file. The reference for HTTP APIs.
gRPC / Protobufprotoc-gen-doc, BufGenerate from .proto files; integrates with API docs sites.
Whole-siteDocusaurus, MkDocs Material, VitePress, NextraCombine generated reference + handwritten guides into one site.
Authoring

Writing Docs the Generator Likes

Document the Public Surface

Every public function, class, and module gets a doc comment. Internal functions get them when their behavior isn't obvious. Comments on private helpers nobody calls externally just add noise.

What to Say
  • What it does — one sentence. Past the generator's auto-extracted signature, that's most of the value.
  • What each parameter is, when not obvious from the type.
  • What it returns, including special cases.
  • What it throws / errors it returns.
  • A short example for non-trivial APIs.
  • Cross-links to related symbols (most generators have a link syntax).
Don't Repeat the Code

// returns the user on a function called getUser() is noise. Document the why, the contract, the edge cases, the units, the side effects — not the obvious.

Lean on Types

In typed languages, a strong signature says most of what a parameter description would. Don't restate types in prose; describe what the value means if it isn't obvious.

Examples Run

Rust's doctests, Python's doctest, Go's testable examples — run every code snippet in the docs as part of the test suite. The docs can't drift; if they did, CI breaks.

The Bigger Picture

Beyond Generated Reference

Diátaxis Quadrants

The most useful framework for organizing docs:

  • Tutorials: "let me learn." Step-by-step, hand-held, beginner-oriented.
  • How-to guides: "I have a goal." Recipe-style for known problems.
  • Reference: "what is this?" — generated.
  • Explanation: "why does this work this way?" Concepts, decisions, architecture.

Trying to put all four into one document fails every time. Different docs serve different needs.

ADRs — Architecture Decision Records

Short markdown files in the repo: title, context, decision, consequences. Capture why a choice was made — the constraints, the alternatives considered, the trade-offs accepted. Six months later, someone asks "why isn't this Postgres?" and the answer is committed history, not folklore.

Hosted Docs Sites

Docusaurus, MkDocs Material, VitePress, Nextra, Mintlify — combine generated API reference, hand-written guides, search, versioning, and dark mode into one deployable site. Most companies that publish docs externally use one of these.

API-Schema-First Docs

For HTTP APIs: write the OpenAPI spec; generate the docs (Redoc, Swagger UI), the SDKs (OpenAPI Generator, openapi-typescript), and the validation. The schema is the source of truth.

Common Mistakes

Where Doc Effort Goes to Waste

  • Wikis as the source of truth. They drift in days; nobody updates them.
  • Auto-generated docs nobody reads. Reference without examples or "getting started" is a directory of names.
  • Onboarding docs for the language, not the codebase. Assume readers know the language; explain this codebase's conventions.
  • Skipping ADRs. Six months later, "why did we pick X?" has no answer except whoever's still around to remember.
  • Marketing docs as engineering docs. Sales-pitch landing pages where readers came to learn how to integrate. Separate them.
Continue

Other Code Quality Tools