M15 Anti Pattern

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:

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

"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