- Home
- Skills
- Zhanghandong
- Rust Skills
- M15 Anti Pattern
m15-anti-pattern_skill
- Shell
565
GitHub Stars
1
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 zhanghandong/rust-skills --skill m15-anti-pattern- SKILL.md4.7 KB
Overview
This skill helps reviewers identify common Rust anti-patterns and practical refactorings. It focuses on design-level issues that mask underlying problems, like excessive cloning, unwraps in production, and inappropriate smart pointer use. Use it to turn symptoms into corrective design changes and more idiomatic Rust code.
How this skill works
The skill inspects code for recurring smells: clone-everywhere, unwraps, unnecessary Rc/Arc, oversized functions/enums, index loops, and unsafe shortcuts. For each finding it asks whether the code is treating a symptom instead of the root cause and points to safer, idiomatic alternatives. It traces suggestions upward to ownership and domain design and downward to concrete implementation fixes.
When to use it
- During code review to flag design-level smells and risky shortcuts
- When diagnosing performance or correctness issues related to ownership and lifetime handling
- Before merging library code to ensure no unwraps or ignored #[must_use] warnings
- When mentoring juniors to explain why a pattern is fragile or non-idiomatic
- When planning a refactor to reduce cloning, panics, or unnecessary indirection
Best practices
- Prefer references or ownership redesign over liberal .clone() usage
- Avoid unwrap() in production; propagate errors with ? or use expect() with context
- Replace index loops with iterators and use &str or Cow<str> to avoid needless allocations
- Limit public fields; encapsulate invariants and provide accessors
- Keep functions small and extract large match arms into methods or trait implementations
Example use cases
- Find and remove unnecessary .clone() calls and propose reference-based alternatives
- Replace pervasive unwrap() usage with a consistent error-handling strategy
- Detect Rc/Arc where single ownership suffices and suggest ownership simplification
- Refactor long functions and giant enums into clearer abstractions and traits
- Advise safe alternatives to unsafe blocks and point to standard library types like Cell/RefCell
FAQ
No. Cloning is valid when ownership copying is intended or cheap. The question is whether clones are masking an ownership design issue; prefer references when appropriate.
When is unwrap acceptable?
unwrap is acceptable in tests, prototypes, or binary main logic where a clear panic is preferable; avoid it in libraries and production paths—use ? or expect with helpful messages instead.