- Home
- Skills
- Huiali
- Rust Skills
- Rust Coding
rust-coding_skill
- Shell
20
GitHub Stars
3
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill huiali/rust-skills --skill rust-coding- SKILL_EN.md2.4 KB
- SKILL_ZH.md4.9 KB
- SKILL.md8.9 KB
Overview
This skill is a Rust coding conventions expert that helps teams apply idiomatic naming, formatting, linting, and design patterns. It focuses on practical rules for naming, conversions (as_/to_/into_), error handling, memory and lifetime discipline, clippy and rustfmt usage, and documentation. The guidance is actionable and ties rules to common pitfalls and verification commands.
How this skill works
It inspects code and returns concrete suggestions: renaming items to Rust conventions, replacing anti-patterns (unnecessary clones, unwraps, index loops), and recommending conversion method semantics. It also recommends clippy and rustfmt configuration, checks for missing docs and SAFETY comments, and maps deprecated patterns to modern alternatives. Outputs include checklist items, small refactor steps, and CI commands to verify fixes.
When to use it
- Code reviews to enforce idiomatic Rust naming and APIs
- Before merging PRs to catch unwraps, unnecessary clones, and wrong accessor names
- When setting up project-wide tooling: rustfmt, clippy, and CI checks
- Refactoring sessions to modernize deprecated libraries and idioms
- Designing public APIs to choose correct ownership and conversion semantics
Best practices
- Name functions and variables snake_case; types and traits CamelCase; constants SCREAMING_SNAKE_CASE
- Use as_ for cheap views, to_ for expensive clones, and into_ for consuming conversions
- Prefer &str in public APIs; use Cow<str> when you may need owned data
- Propagate errors with ?; use expect only for guaranteed invariants; avoid unwrap in library code
- Run cargo fmt and cargo clippy in CI; fix clippy warnings and treat important lints as errors
- Document public items with /// and module-level docs with //!; add examples and panic docs when applicable
Example use cases
- Rename accessor methods to remove get_ prefix and fix clippy::wrong_self_convention warnings
- Convert APIs that return owned String to &str parameters and use Cow where conditional allocation is needed
- Replace lazy_static or once_cell with std synchronization types when bumping Rust version
- Audit a crate for unnecessary clone() calls and replace with references or owned transfers
- Add SAFETY comments to unsafe blocks and ensure lifetimes use meaningful names
FAQ
Use as_ for cheap borrows, to_ for cloning/allocating conversions, and into_ for consuming ownership transfers.
When is expect acceptable over unwrap?
Use expect when an invariant guaranteed by construction exists; prefer ? or propagate errors in library code to avoid panics.