| name | documenting-rust-code |
| description | Rust documentation practices for HASH codebase. Use when writing doc comments, documenting functions/types/traits/modules, creating error sections, using intra-doc links, or following rustdoc conventions. |
| license | AGPL-3.0 |
| metadata | {"triggers":{"type":"domain","enforcement":"suggest","priority":"high","keywords":["rustdoc","doc comment","documentation","intra-doc link"],"intent-patterns":["\\bdocument(ing|ation)?\\b.*?\\b(rust|function|type|struct|enum|trait|module)\\b","\\b(write|add|create)\\b.*?\\bdoc\\s*comment\\b","\\b#\\s*(Errors|Panics|Examples|Arguments)\\b"]}} |
Rust Documentation Practices
Comprehensive guidance on documenting Rust code in the HASH repository following rustdoc conventions.
Core Principles
Follow high-quality standards like time, jiff, and serde:
ā
DO:
- Begin every doc comment with single-line summary
- Use intra-doc links for all type references
- Document all error conditions with
# Errors
- Include practical examples for public APIs
- Link standard library types: [
Vec], [HashMap], etc.
- Use inline parameter descriptions for simple functions (0-2 params)
- Describe return values in main text, not separate sections
ā DON'T:
- Document standard trait implementations (
Debug, Display, From)
- Add separate
# Returns sections (inline instead)
- Mention variable types already in signatures
- Use comments on same line as code
- Skip error documentation for fallible functions
Quick Reference
Basic Doc Comment
pub fn get_entity(&self, id: EntityId) -> Result<Entity, Report<EntityError>> {
Intra-Doc Links
Documentation Patterns
Simple Functions (0-2 params)
Describe parameters inline:
Complex Functions (3+ params)
Use explicit # Arguments section:
Error Documentation
Module Documentation
Examples with Error Handling
Verification
cargo doc --no-deps --all-features
References