# Rust Docs Guidelines

> Guidelines for writing Rust documentation. Use this when you want to write Rust documentation.

- Skill: `redisearch/rust-docs-guidelines` (Agent Skill)
- Install (CLI): `npx skillmds@latest add redisearch/rust-docs-guidelines`
- Raw SKILL.md: https://api.skillmd.com/api/skills/redisearch/rust-docs-guidelines/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: RediSearch (https://skillmd.com/u/redisearch)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/redisearch/rust-docs-guidelines

---


# Rust Docs Guidelines

Standards to follow when writing Rust documentation.

## Guidelines

- Key concepts should be explained only once. All other documentation should use an intra-documentation link to the first explanation.
- Always use an intra-documentation link when mentioning a Rust symbol (type, function, constant, etc.).
- In a `# Safety` section, link the word `valid` to std's pointer-validity rules: write it as
  `[valid]` and put this reference definition at the end of the doc block —
  ```text
  [valid]: https://doc.rust-lang.org/std/ptr/index.html#safety
  ```
  Only where it means pointer or memory validity — `valid UTF-8`, a valid enum variant, a valid
  nul terminator and a by-value struct whose fields must agree keep their plain form, since
  std's definition says nothing about them.
  A duration clause such as "must remain valid for the lifetime of the returned iterator" does
  mean it, so link it as well; the duration it adds is orthogonal to what validity means.
  A callback parameter is the other way round: std's rules cover accesses through data
  pointers, not whether an address is callable under a given ABI, so require the signature
  to be `[ABI-compatible]` instead and define it as —
  ```text
  [ABI-compatible]: https://doc.rust-lang.org/std/primitive.fn.html#abi-compatibility
  ```
  Non-doc `// SAFETY:` comments keep the plain form too: rustdoc does not render them, so the
  brackets would stay literal text.
- Avoid referring to specific lines or line ranges, as they may change over time.
  Use line comments if the documentation needs to be attached to a specific code section inside
  a function/method body.
- Focus on why, not how.
  In particular, avoid explaining trivial implementation details in line comments.
- Refer to constants using intra-documentation links. Don't hard-code their values in the documentation of other items.
- Intra-documentation links to private items are preferable to duplication. Add `#[allow(rustdoc::private_intra_doc_links)]` where relevant.