reidond/kedra/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

1. What would idiomatic code look like?

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

1. 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