Documentation Style Guide
Guidelines for writing SochDB documentation.
Principlesβ
- Clarity over cleverness β Write for understanding, not impression
- Scannable β Use headers, lists, and tables
- Actionable β Include working code examples
- Current β Keep docs in sync with code
Structureβ
Page Templateβ
# Page Title
Brief description of what this page covers.
---
## Table of Contents (optional, for long pages)
---
## First Section
Content...
### Subsection
More content...
---
## See Also
- [Related Page](./related.md)
DiΓ‘taxis Quadrantsβ
Place each document in the appropriate quadrant:
| Type | Purpose | Location |
|---|---|---|
| Tutorial | Learning-oriented | docs/tutorials/ |
| How-to | Problem-oriented | docs/cookbook/ |
| Reference | Information-oriented | docs/reference/ or docs/API.md |
| Explanation | Understanding-oriented | docs/internals/ or docs/explanation/ |
Writing Styleβ
Voiceβ
- Use second person ("you can...") for instructions
- Use active voice ("SochDB stores..." not "data is stored...")
- Be direct ("Run this command" not "You might want to run...")
Headingsβ
- Use sentence case (capitalize first word only)
- Make headings descriptive ("How to configure logging" not "Logging")
- Limit to 3 levels (H2, H3, H4)
Code Examplesβ
Always include:
- Language identifier in code fences
- Runnable examples when possible
- Expected output for commands
# β
Good: Complete, runnable example
from sochdb import Database
db = Database.open("./my_db")
db.put(b"key", b"value")
print(db.get(b"key")) # Output: b"value"
db.close()
# β Bad: Incomplete, can't run
db.put("key", "value") # Missing import, wrong type
Listsβ
- Use bullet lists for unordered items
- Use numbered lists for sequential steps
- Use tables for structured data with multiple attributes
Linksβ
- Use relative paths for internal links
- Include descriptive text (not "click here")
- Link to specific sections when helpful
# β
Good
See the [configuration reference](./reference/configuration.md#storage-options)
# β Bad
Click [here](./reference/configuration.md) for more info
Formattingβ
Codeβ
-
Inline code for: file names, function names, commands, paths
sochdb.toml,SochValue,cargo test,/var/lib/sochdb
-
Code blocks for: multi-line code, command output, file contents
Tablesβ
Use tables for comparison and reference:
| Feature | Free | Pro |
|---------|------|-----|
| Storage | 1 GB | 100 GB |
| Support | Community | Priority |
Calloutsβ
Use blockquotes for important notes:
> **Note:** This is important information.
> **Warning:** This action cannot be undone.
> **Tip:** This makes things easier.
Content Guidelinesβ
Tutorialsβ
- Start with a clear goal
- List prerequisites
- Provide step-by-step instructions
- Include verification steps
- End with next steps
How-To Guidesβ
- Start with the problem
- Provide the solution immediately
- Add examples
- Discuss alternatives/trade-offs
- Link to related recipes
Referenceβ
- Be complete (document all options)
- Use consistent format for each entry
- Include types and defaults
- Provide examples for complex options
Explanationβ
- Start with why before how
- Use diagrams for architecture
- Explain trade-offs in decisions
- Link to source code when relevant
Diagramsβ
Use ASCII diagrams for architecture:
βββββββββββ βββββββββββ
β Client ββββββΆβ Server β
βββββββββββ βββββββββββ
For complex diagrams, use Mermaid (if supported) or link to images.
Versioningβ
API Changesβ
Mark deprecated features:
> **Deprecated in v0.2:** Use `new_method()` instead.
Version-Specific Contentβ
> **New in v0.2:** This feature was added in version 0.2.
Review Checklistβ
Before submitting documentation:
- Code examples compile/run
- Links work (no 404s)
- Spelling and grammar checked
- Follows style guide
- Placed in correct DiΓ‘taxis quadrant
- Added to navigation/index
Toolsβ
Spell Checkβ
# Using aspell
find docs -name "*.md" -exec aspell check {} \;
Link Checkβ
# Using markdown-link-check
npx markdown-link-check docs/**/*.md
Previewβ
# Using grip (GitHub-flavored markdown)
pip install grip
grip docs/index.md
See Alsoβ
- Testing Guide β How to test
- DiΓ‘taxis Framework β Documentation methodology
- Google Developer Documentation Style Guide