---

name: m15-anti-pattern description: "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, 反模式, 常见错误, 代码异味, 最佳实践, 地道写法" user-invocable: false

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

---

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:

Copy"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)

---

Trace Down ↓

To implementation (Layer 1):

Copy"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

Code Smell → Refactoring

---

Common Error Patterns

---

Deprecated → Better

---

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