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:

Is this symptom or cause?

• Clone to avoid borrow? → Ownership design issue

• Unwrap "because it won't fail"? → Unhandled case

What would idiomatic code look like?

• References instead of clones

• Iterators instead of index loops

• Pattern matching instead of flags

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