Expand guidelines for examples
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- documentation
Research direction
Start with the code-examples section of docs/authoring.md and review the linked TRPL listings and Google code samples guidance. Document decisions covering example frequency, naming, realism, length, inline versus included examples, testing, and rustfmt usage; the issue is complete when these guidelines are added to the authoring documentation.
Written by the indexing model from the issue text.
Description
I'd like to extend the examples guidelines to provide better guidance on writing examples.
- How often should there be examples? Are there any guidelines for when they should and should not be used?
- Should there be naming conventions, such as avoiding nonsense terms like foo/bar/baz, and using realistic terms instead.
- ehuss's preference: I would encourage not using nonsense terms, and try to use names that are illustrative of the concept whenever possible (example).
- Should the examples prefer to be realistic of what a user would actually write?
That can be difficult, since that often requires longer examples. Unrealistic or trivial examples can be confusing. - Are there guidelines for balancing length versus clarity? There are times when to illustrate some concept, it may require a significant amount of code. At what point is too much? mdBook supports hiding irrelevant portions of code, but that has limitations.
- Should example code be inline within the text, or outline (like TRPL) and use includes? Inline is easier to author, outline is easier to test.
- How much should we rely on outline examples or tests (for example, the links to the testsuite)?
- Should examples be formatted with rustfmt?
- Any non-default options?
References:
- Dominant language
- Rust
- Stars
- 1.6k
- Forks
- 607
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 12
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-lang/reference
-
A-const-eval A-undefined-behavior
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
A-resolve
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
A-coercions
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
All issues in rust-lang/reference
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100