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
&T over .clone() unless ownership transfer is required
- Use
&str over String, &[T] over Vec<T> in function parameters
- Small
Copy types (≤24 bytes) can be passed by value
- Use
Cow<'_, T> when ownership is ambiguous
Error Handling
- Return
Result<T, E> for fallible operations; avoid panic! in production
- Never use
unwrap()/expect() outside tests
- Use
thiserror for library errors, anyhow for binaries only
- Prefer
? operator over match chains for error propagation
Performance
- Always benchmark with
--release flag
- Run
cargo clippy -- -D clippy::perf for 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 cloning
large_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 insta for snapshot testing generated output
Generics & Dispatch
- Prefer generics (static dispatch) for performance-critical code
- Use
dyn Trait only 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
TODO needs a linked issue: // TODO(#42): ...
- Enable
#![deny(missing_docs)] for libraries
1---2name: rust-best-practices3description: 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.4license: MIT5---6
7# Rust Best Practices
8
9Apply these guidelines when writing or reviewing Rust code. Based on Apollo GraphQL's [Rust Best Practices Handbook](https://github.com/apollographql/rust-best-practices).
10
11## Best Practices Reference
12
13Before 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:
14
15- [Chapter 1 - Coding Styles and Idioms](references/chapter_01.md): Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments
16- [Chapter 2 - Clippy and Linting](references/chapter_02.md): Clippy configuration, important lints, workspace lint setup
17- [Chapter 3 - Performance Mindset](references/chapter_03.md): Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
18- [Chapter 4 - Error Handling](references/chapter_04.md): Result vs panic, thiserror vs anyhow, error hierarchies
19- [Chapter 5 - Automated Testing](references/chapter_05.md): Test naming, one assertion per test, snapshot testing
20- [Chapter 6 - Generics and Dispatch](references/chapter_06.md): Static vs dynamic dispatch, trait objects
21- [Chapter 7 - Type State Pattern](references/chapter_07.md): Compile-time state safety, when to use it
22- [Chapter 8 - Comments vs Documentation](references/chapter_08.md): When to comment, doc comments, rustdoc
23- [Chapter 9 - Understanding Pointers](references/chapter_09.md): Thread safety, Send/Sync, pointer types
24
25## Quick Reference
26
27### Borrowing & Ownership
28- Prefer `&T` over `.clone()` unless ownership transfer is required
29- Use `&str` over `String`, `&[T]` over `Vec<T>` in function parameters
30- Small `Copy` types (≤24 bytes) can be passed by value
31- Use `Cow<'_, T>` when ownership is ambiguous
32
33### Error Handling
34- Return `Result<T, E>` for fallible operations; avoid `panic!` in production
35- Never use `unwrap()`/`expect()` outside tests
36- Use `thiserror` for library errors, `anyhow` for binaries only
37- Prefer `?` operator over match chains for error propagation
38
39### Performance
40- Always benchmark with `--release` flag
41- Run `cargo clippy -- -D clippy::perf` for performance hints
42- Avoid cloning in loops; use `.iter()` instead of `.into_iter()` for Copy types
43- Prefer iterators over manual loops; avoid intermediate `.collect()` calls
44
45### Linting
46Run regularly: `cargo clippy --all-targets --all-features --locked -- -D warnings`
47
48Key lints to watch:
49- `redundant_clone` - unnecessary cloning
50- `large_enum_variant` - oversized variants (consider boxing)
51- `needless_collect` - premature collection
52
53Use `#[expect(clippy::lint)]` over `#[allow(...)]` with justification comment.
54
55### Testing
56- Name tests descriptively: `process_should_return_error_when_input_empty()`
57- One assertion per test when possible
58- Use doc tests (`///`) for public API examples
59- Consider `cargo insta` for snapshot testing generated output
60
61### Generics & Dispatch
62- Prefer generics (static dispatch) for performance-critical code
63- Use `dyn Trait` only when heterogeneous collections are needed
64- Box at API boundaries, not internally
65
66### Type State Pattern
67Encode valid states in the type system to catch invalid operations at compile time:
68```rust
69struct Connection<State> { /* ... */ _state: PhantomData<State> }
70struct Disconnected;
71struct Connected;
72
73impl Connection<Connected> {
74 fn send(&self, data: &[u8]) { /* only connected can send */ }
75}
76```
77
78### Documentation
79- `//` comments explain *why* (safety, workarounds, design rationale)
80- `///` doc comments explain *what* and *how* for public APIs
81- Every `TODO` needs a linked issue: `// TODO(#42): ...`
82- Enable `#![deny(missing_docs)]` for libraries