Rust best practices
Skill ComeOnOliver/skillshub/skills/Harmeet10000/skills/rust-best-practices
Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. Use this skill when: (1) writing new Rust code or functions, (2) reviewing or refactoring existing Rust code, (3) deciding between borrowing vs cloning or ownership patterns, (4) implementing error handling with Result types, (5) optimizing Rust code for performance, (6) writing tests or documentation for Rust projects.From its SKILL.md
npx -y skills add ComeOnOliver/skillshub --skill rust-best-practicesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.2 KB, 890 tokens by cl100k_base, as published. Nobody here has run it
Rust Best Practices
Apply these guidelines when writing or reviewing Rust code. Based on Apollo GraphQL's Rust Best Practices Handbook.
Best Practices Reference
Before reviewing, familiarize yourself with Apollo's Rust best practices. Read ALL relevant chapters in the same turn in parallel. Reference these files when providing feedback:
- Chapter 1 - Coding Styles and Idioms: Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments
- Chapter 2 - Clippy and Linting: Clippy configuration, important lints, workspace lint setup
- Chapter 3 - Performance Mindset: Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
- Chapter 4 - Error Handling: Result vs panic, thiserror vs anyhow, error hierarchies
- Chapter 5 - Automated Testing: Test naming, one assertion per test, snapshot testing
- Chapter 6 - Generics and Dispatch: Static vs dynamic dispatch, trait objects
- Chapter 7 - Type State Pattern: Compile-time state safety, when to use it
- Chapter 8 - Comments vs Documentation: When to comment, doc comments, rustdoc
- Chapter 9 - Understanding Pointers: Thread safety, Send/Sync, pointer types
Quick Reference
Borrowing & Ownership
- Prefer
&Tover.clone()unless ownership transfer is required - Use
&stroverString,&[T]overVec<T>in function parameters - Small
Copytypes (≤24 bytes) can be passed by value - Use
Cow<'_, T>when ownership is ambiguous
Error Handling
- Return
Result<T, E>for fallible operations; avoidpanic!in production - Never use
unwrap()/expect()outside tests - Use
thiserrorfor library errors,anyhowfor binaries only - Prefer
?operator over match chains for error propagation
Performance
- Always benchmark with
--releaseflag - Run
cargo clippy -- -D clippy::perffor performance hints - Avoid cloning in loops; use
.iter()instead of.into_iter()for Copy types - Prefer iterators over manual loops; avoid intermediate
.collect()calls
Linting
Run regularly: cargo clippy --all-targets --all-features --locked -- -D warnings
Key lints to watch:
redundant_clone- unnecessary cloninglarge_enum_variant- oversized variants (consider boxing)needless_collect- premature collection
Use #[expect(clippy::lint)] over #[allow(...)] with justification comment.
Testing
- Name tests descriptively:
process_should_return_error_when_input_empty() - One assertion per test when possible
- Use doc tests (
///) for public API examples - Consider
cargo instafor snapshot testing generated output
Generics & Dispatch
- Prefer generics (static dispatch) for performance-critical code
- Use
dyn Traitonly when heterogeneous collections are needed - Box at API boundaries, not internally
Type State Pattern
Encode valid states in the type system to catch invalid operations at compile time:
struct Connection<State> { /* ... */ _state: PhantomData<State> }
struct Disconnected;
struct Connected;
impl Connection<Connected> {
fn send(&self, data: &[u8]) { /* only connected can send */ }
}
Documentation
//comments explain why (safety, workarounds, design rationale)///doc comments explain what and how for public APIs- Every
TODOneeds a linked issue:// TODO(#42): ... - Enable
#![deny(missing_docs)]for libraries
What ships with it
85.5 KB alongside SKILL.md
GitHub clipped this repository’s file list, so this is at least 9 files and may be more.
references/
- chapter_01.md16.9 KB
- chapter_02.md5.3 KB
- chapter_03.md8.6 KB
- chapter_04.md6.9 KB
- chapter_05.md13.8 KB
- chapter_06.md6.7 KB
- chapter_07.md8.0 KB
- chapter_08.md9.9 KB
- chapter_09.md9.3 KB
Gives 0 of the 12 instructions most docs writing skills give in 890 tokens
Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-07
- Announce the skill at startin 54 of 1637, across 26 files
- Convert legacy doc files before editingin 45 of 1637, across 7 files
- Predict questions readers might askin 42 of 1637, across 4 files
- Generate clarifying questions for initial contextin 42 of 1637, across 3 files
- Create document scaffold with placeholder textin 42 of 1637, across 3 files
- Brainstorm content options for each sectionin 42 of 1637, across 3 files
- Test the document with a fresh context-less instancein 42 of 1637, across 3 files
- Include exact file paths in every taskin 42 of 1637, across 15 files
- Ask interview questions one at a timein 42 of 1637, across 27 files
- Apply surgical edits during refinementin 41 of 1637, across 2 files
- Offer structured workflow or freeformin 40 of 1637, across 1 file
- Ask for document meta-contextin 40 of 1637, across 2 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.