skilld
All skills
zhanghandong avatar

/m15-anti-pattern

@f464484
by Alexzhanghandong/rust-skills1.5k stars
115

Use when reviewing code for anti-patterns. Keywords: anti-pattern, common mistake, pitfall, code smell, bad practice, code review, is this an anti-pattern, better way to do this, common mistake to avoid, why is this bad, idiomatic way, beginner mistake, fighting borrow checker, clone everywhere, unwrap in production, should I refactor, 反模式, 常见错误, 代码异味, 最佳实践, 地道写法

Ask your Agent

Use this Skill: https://skilld.dev/gh/zhanghandong/rust-skills/m15-anti-pattern

This session only. Nothing lands on disk.

SKILL.md

≈105 tokens always: the name and description. ≈1.1k when used: this file. ≈2.1k more on demand in 1 file.

Anti-Patterns

Layer 2: Design Choices

Core Question

Is this pattern hiding a design problem?

When reviewing code:

  • Is this solving the symptom or the cause?
  • Is there a more idiomatic approach?
  • Does this fight or flow with Rust?

Anti-Pattern → Better Pattern

Anti-Pattern Why Bad Better
.clone() everywhere Hides ownership issues Proper references or ownership
.unwrap() in production Runtime panics ?, expect, or handling
Rc when single owner Unnecessary overhead Simple ownership
unsafe for convenience UB risk Find safe pattern
OOP via Deref Misleading API Composition, traits
Giant match arms Unmaintainable Extract to methods
String everywhere Allocation waste &str, Cow<str>
Ignoring #[must_use] Lost errors Handle or let _ =

Thinking Prompt

When seeing suspicious code:

  1. Is this symptom or cause?

    • Clone to avoid borrow? → Ownership design issue
    • Unwrap "because it won't fail"? → Unhandled case

  2. What would idiomatic code look like?

    • References instead of clones
    • Iterators instead of index loops
    • Pattern matching instead of flags

  3. Does this fight Rust?

    • Fighting borrow checker → restructure
    • Excessive unsafe → find safe pattern

Trace Up ↑

To design understanding:

"Why does my code have so many clones?"
    ↑ Ask: Is the ownership model correct?
    ↑ Check: m09-domain (data flow design)
    ↑ Check: m01-ownership (reference patterns)
Anti-Pattern Trace To Question
Clone everywhere m01-ownership Who should own this data?
Unwrap everywhere m06-error-handling What's the error strategy?
Rc everywhere m09-domain Is ownership clear?
Fighting lifetimes m09-domain Should data structure change?

Trace Down ↓

To implementation (Layer 1):

"Replace clone with proper ownership"
    ↓ m01-ownership: Reference patterns
    ↓ m02-resource: Smart pointer if needed

"Replace unwrap with proper handling"
    ↓ m06-error-handling: ? operator
    ↓ m06-error-handling: expect with message

Top 5 Beginner Mistakes

Rank Mistake Fix
1 Clone to escape borrow checker Use references
2 Unwrap in production Propagate with ?
3 String for everything Use &str
4 Index loops Use iterators
5 Fighting lifetimes Restructure to own data

Code Smell → Refactoring

Smell Indicates Refactoring
Many .clone() Ownership unclear Clarify data flow
Many .unwrap() Error handling missing Add proper handling
Many pub fields Encapsulation broken Private + accessors
Deep nesting Complex logic Extract methods
Long functions Multiple responsibilities Split
Giant enums Missing abstraction Trait + types

Common Error Patterns

Error Anti-Pattern Cause Fix
E0382 use after move Cloning vs ownership Proper references
Panic in production Unwrap everywhere ?, matching
Slow performance String for all text &str, Cow
Borrow checker fights Wrong structure Restructure
Memory bloat Rc/Arc everywhere Simple ownership

Deprecated → Better

Deprecated Better
Index-based loops .iter(), .enumerate()
collect::<Vec<_>>() then iterate Chain iterators
Manual unsafe cell Cell, RefCell
mem::transmute for casts as or TryFrom
Custom linked list Vec, VecDeque
lazy_static! std::sync::OnceLock

Quick Review Checklist

  • No .clone() without justification
  • No .unwrap() in library code
  • No pub fields with invariants
  • No index loops when iterator works
  • No String where &str suffices
  • No ignored #[must_use] warnings
  • No unsafe without SAFETY comment
  • No giant functions (>50 lines)

Related Skills

When See
Ownership patterns m01-ownership
Error handling m06-error-handling
Mental models m14-mental-model
Performance m10-performance

Source: SKILL.md on GitHub

Third-party checks

No alerts16d5 checks · Risk SAFE
  • Gen Agent Trust Hub16d

    The analyzed skill contains only documentation, checklists, and code examples intended to help users identify and fix common Rust anti-patterns. It does not execute any code, invoke tools, or perform network/file system operations.

  • Socket16d

    No alerts

  • Snyk16d

    Risk: LOW · No issues

  • Runlayer7mo

    2 files scanned · No issues

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Provenance

Signed by skilld at f464484. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub last month.

Steadyupdated 8 months ago

Capability

user-invocable
false

Topics

  • Rust
  • Refactoring
  • anti-pattern
  • code-review
  • code-smell
  • ownership
  • error-handling
  • best-practices
  • idiomatic

README badge

README badge for zhanghandong/rust-skills

What it does

Identifies and refactors common Rust anti-patterns like excessive `.clone()`, `.unwrap()` in production code, and fighting the borrow checker. Helps code reviewers spot design issues masked by symptom-level fixes and suggest idiomatic alternatives.

Generated from the current SKILL.md.

Frequently asked

Does this skill help me identify anti-patterns while writing code?
No. This skill is user-invocable: false, meaning it's designed for AI agents to consult during code review, not for interactive use while coding. It's best used when reviewing existing code for design problems.
What Rust anti-patterns does this skill cover?
It covers common patterns like excessive .clone() calls, .unwrap() in production code, unnecessary Rc usage, String overuse instead of &str, fighting the borrow checker, and large unmaintainable code structures. It traces problems back to underlying design issues and forward to specific fixes.
Does this skill point to other resources for fixing anti-patterns?
Yes. The skill traces anti-patterns up to layer 3 skills like m01-ownership and m06-error-handling for root cause analysis, and down to layer 1 implementation guidance. It also cross-references m09-domain for data flow design and m10-performance for optimization.
How does this differ from a generic Rust linter or clippy?
This skill focuses on design-level anti-patterns and reasoning about *why* code is problematic, not just syntax warnings. It provides mental models for identifying whether code is solving a symptom or the underlying cause, and guides refactoring strategy.

Generated from the current SKILL.md. These answers refresh after source changes.