mcpField
R
rust-best-practices

rust-best-practices

github.com/apollographqlDevelopment12121.3k installsUpdated 1d ago
Repository

About rust-best-practices

rust-best-practices is a reference skill for writing and reviewing Rust code, based on Apollo GraphQL's Rust Best Practices Handbook. It covers idioms, error handling, performance, linting, testing, types, and documentation.

Key features

  1. 01Ownership and borrowing guidance
  2. 02Error-handling conventions
  3. 03Performance and linting advice
  4. 04Testing recommendations
  5. 05Generics and type-state guidance
  6. 06Documentation practices

Use cases

  1. 01Reviewing Rust code for idioms
  2. 02Choosing error-handling approaches
  3. 03Checking performance and Clippy concerns
  4. 04Planning tests and API documentation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/apollographql/skills --skill rust-best-practices

After installing, type/rust-best-practicesin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
chapter_01.md
chapter_02.md
chapter_03.md
chapter_04.md
chapter_05.md
chapter_06.md
chapter_07.md
chapter_08.md
chapter_09.md

Details

From the project README

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:

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

Comments

Markdown supported