home / skills / zhanghandong / rust-skills / coding-guidelines

coding-guidelines skill

safe

This skill helps you apply Rust coding guidelines for naming, data types, error handling, and formatting to improve code quality.

npx playbooks add skill zhanghandong/rust-skills --skill coding-guidelines

Review the files below or copy the command above to add this skill to your agents.

Files (3)

SKILL.md

3.0 KB

---
name: coding-guidelines
description: "Use when asking about Rust code style or best practices. Keywords: naming, formatting, comment, clippy, rustfmt, lint, code style, best practice, P.NAM, G.FMT, code review, naming convention, variable naming, function naming, type naming, 命名规范, 代码风格, 格式化, 最佳实践, 代码审查, 怎么命名"
source: https://rust-coding-guidelines.github.io/rust-coding-guidelines-zh/
user-invocable: false
---

# Rust Coding Guidelines (50 Core Rules)

## Naming (Rust-Specific)

| Rule | Guideline |
|------|-----------|
| No `get_` prefix | `fn name()` not `fn get_name()` |
| Iterator convention | `iter()` / `iter_mut()` / `into_iter()` |
| Conversion naming | `as_` (cheap &), `to_` (expensive), `into_` (ownership) |
| Static var prefix | `G_CONFIG` for `static`, no prefix for `const` |

## Data Types

| Rule | Guideline |
|------|-----------|
| Use newtypes | `struct Email(String)` for domain semantics |
| Prefer slice patterns | `if let [first, .., last] = slice` |
| Pre-allocate | `Vec::with_capacity()`, `String::with_capacity()` |
| Avoid Vec abuse | Use arrays for fixed sizes |

## Strings

| Rule | Guideline |
|------|-----------|
| Prefer bytes | `s.bytes()` over `s.chars()` when ASCII |
| Use `Cow<str>` | When might modify borrowed data |
| Use `format!` | Over string concatenation with `+` |
| Avoid nested iteration | `contains()` on string is O(n*m) |

## Error Handling

| Rule | Guideline |
|------|-----------|
| Use `?` propagation | Not `try!()` macro |
| `expect()` over `unwrap()` | When value guaranteed |
| Assertions for invariants | `assert!` at function entry |

## Memory

| Rule | Guideline |
|------|-----------|
| Meaningful lifetimes | `'src`, `'ctx` not just `'a` |
| `try_borrow()` for RefCell | Avoid panic |
| Shadowing for transformation | `let x = x.parse()?` |

## Concurrency

| Rule | Guideline |
|------|-----------|
| Identify lock ordering | Prevent deadlocks |
| Atomics for primitives | Not Mutex for bool/usize |
| Choose memory order carefully | Relaxed/Acquire/Release/SeqCst |

## Async

| Rule | Guideline |
|------|-----------|
| Sync for CPU-bound | Async is for I/O |
| Don't hold locks across await | Use scoped guards |

## Macros

| Rule | Guideline |
|------|-----------|
| Avoid unless necessary | Prefer functions/generics |
| Follow Rust syntax | Macro input should look like Rust |

## Deprecated → Better

| Deprecated | Better | Since |
|------------|--------|-------|
| `lazy_static!` | `std::sync::OnceLock` | 1.70 |
| `once_cell::Lazy` | `std::sync::LazyLock` | 1.80 |
| `std::sync::mpsc` | `crossbeam::channel` | - |
| `std::sync::Mutex` | `parking_lot::Mutex` | - |
| `failure`/`error-chain` | `thiserror`/`anyhow` | - |
| `try!()` | `?` operator | 2018 |

## Quick Reference

```
Naming: snake_case (fn/var), CamelCase (type), SCREAMING_CASE (const)
Format: rustfmt (just use it)
Docs: /// for public items, //! for module docs
Lint: #![warn(clippy::all)]
```

Claude knows Rust conventions well. These are the non-obvious Rust-specific rules.

Overview

This skill helps Rust developers apply idiomatic naming, formatting, linting, and best-practice rules to real code. It focuses on actionable, non-obvious Rust conventions—naming patterns, data and string handling, error and memory strategies, concurrency and async advice, and modern replacements for deprecated patterns. Use it to get clear, code-review-ready guidance tailored to Rust projects.

How this skill works

Ask about a specific snippet, naming choice, lint warning, or design trade-off and the skill inspects the intent and context to recommend concrete fixes. It maps problems to Rust conventions (snake_case/CamelCase/SCREAMING_CASE), rustfmt/clippy guidance, and domain-level suggestions like newtypes, pre-allocation, or choosing atomics versus locks. Recommendations include short code examples or one-line refactors when useful.

When to use it

Naming functions, types, variables, constants, or statics in a Rust codebase
Interpreting or fixing clippy warnings and rustfmt issues
Designing data types: newtypes, slices, Vec vs arrays, and preallocation
Improving error handling with ?/expect/anyhow/thiserror patterns
Choosing concurrency primitives and async design choices

Best practices

Follow Rust naming: snake_case for functions/vars, CamelCase for types, SCREAMING_CASE for consts/statics
Avoid get_ prefix; prefer name() for accessors and standard iter/into_iter conventions
Prefer newtypes for domain semantics and pre-allocate Vec/String when sizes known
Use ? for propagation, expect() only when guaranteed, and prefer thiserror/anyhow for ergonomic errors
Run rustfmt and enable #![warn(clippy::all)] as part of CI
Avoid holding locks across await points; prefer atomics for simple primitives and pick memory ordering explicitly

Example use cases

Rename public API items to idiomatic Rust names and update docs/comments
Convert a tuple/string type to a newtype to add domain guarantees and custom impls
Refactor code to use Vec::with_capacity and slice patterns for performance
Resolve clippy suggestions and explain which lints to allow or silence and why
Replace deprecated crates (lazy_static, once_cell) with std alternatives when on modern Rust versions

FAQ

When should I use as_, to_, or into_ prefixes?

Use as_ for cheap borrow-like conversions, to_ for potentially expensive cloning/formatting, and into_ when consuming ownership for conversion.

Should I prefer bytes() or chars() for string processing?

Prefer bytes() for ASCII or binary-oriented processing; use chars() only when you need proper Unicode-grapheme semantics and accept the performance cost.