首页/AI 代码生成与质效/rust-best-practices
R

rust-best-practices

by @apollographqlv
4.5(100)

提供基于Apollo GraphQL的Rust惯用代码编写指南,帮助开发者遵循最佳实践,提升代码质量。

rust-languagememory-safetyconcurrencyperformance-optimizationerror-handlingGitHub
安装方式
npx skills add apollographql/skills --skill rust-best-practices
compare_arrows

Before / After 效果对比

1
使用前

在没有遵循Rust最佳实践时,开发者可能会编写出虽然功能正确但不够“地道”的代码。这可能导致内存管理不当、并发问题或难以理解的生命周期错误,降低了代码的可维护性和性能。

使用后

遵循基于Apollo GraphQL的Rust最佳实践,能够指导开发者编写出符合Rust语言习惯、类型安全且高性能的后端代码。这不仅提升了代码的健壮性和可读性,还充分利用了Rust的并发优势,确保了服务的稳定运行。

SKILL.md

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

用户评价 (0)

发表评价

效果
易用性
文档
兼容性

暂无评价

统计数据

安装量10.5K
评分4.5 / 5.0
版本
更新日期2026年5月23日
对比案例1 组

用户评分

4.5(100)
5
23%
4
52%
3
23%
2
2%
1
0%

为此 Skill 评分

0.0

兼容平台

🔧Claude Code
🔧OpenClaw
🔧OpenCode
🔧Codex
🔧Gemini CLI
🔧GitHub Copilot
🔧Amp
🔧Kimi CLI

时间线

创建2026年3月16日
最后更新2026年5月23日