m15-anti-pattern

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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?

该模式是否隐藏了设计问题？

在审查代码时：

该写法是解决症状还是根源问题？
是否存在更地道的实现方式？
该写法是与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 _ =`

反模式	问题所在	更优方案
滥用 `.clone()`	掩盖所有权问题	使用正确的引用或所有权管理
生产环境中使用 `.unwrap()`	会导致运行时恐慌	使用 `?` 、 `expect` 或错误处理逻辑
单所有权场景下使用 `Rc`	带来不必要的性能开销	使用简单的所有权管理
为图方便使用 `unsafe`	存在未定义行为风险	寻找安全的实现模式
通过 `Deref` 实现OOP	API具有误导性	使用组合、trait
巨型match分支	难以维护	提取为独立方法
滥用 `String`	造成内存分配浪费	使用 `&str` 、 `Cow<str>`
忽略 `#[must_use]` 标记	丢失错误信息	处理错误或使用 `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

看到可疑代码时：

该写法是解决症状还是根源？
- 通过clone规避借用问题？ → 所有权设计存在问题
- 认为「不会出错」而使用unwrap？ → 存在未处理的场景
地道的Rust代码应该是什么样的？
- 使用引用而非clone
- 使用迭代器而非下标循环
- 使用模式匹配而非标志位
该写法是否与Rust的设计理念相悖？
- 与Borrow Checker对抗 → 重构代码结构
- 过度使用unsafe → 寻找安全的实现模式

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?

指向设计层面的理解：

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

反模式	追溯至	问题
滥用.clone()	m01-ownership	谁应该拥有该数据的所有权？
滥用.unwrap()	m06-error-handling	错误处理策略是什么？
滥用Rc	m09-domain	所有权是否清晰？
与生命周期对抗	m09-domain	是否需要修改数据结构？

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

指向实现层面（第一层）：

"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

排名	错误	修复方案
1	通过clone规避Borrow Checker	使用引用
2	生产环境中使用unwrap	使用 `?` 传播错误
3	所有场景都使用String	使用 `&str`
4	下标循环	使用迭代器
5	与生命周期对抗	重构代码以合理管理所有权

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

异味	预示问题	重构方案
大量使用 `.clone()`	所有权不清晰	明确数据流
大量使用 `.unwrap()`	缺失错误处理	添加完善的错误处理逻辑
大量 `pub` 字段	封装性被破坏	使用私有字段+访问器方法
深层嵌套	逻辑过于复杂	提取为独立方法
超长函数	承担多个职责	拆分函数
巨型枚举	缺失抽象	使用Trait+类型

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

错误	反模式诱因	修复方案
E0382 use after move	Clone与所有权管理不当	使用正确的引用
生产环境中出现恐慌	滥用unwrap	使用 `?` 、模式匹配
性能缓慢	所有文本都使用String	使用&str、Cow
与Borrow Checker对抗	代码结构不合理	重构代码结构
内存膨胀	滥用Rc/Arc	使用简单的所有权管理

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`

已弃用写法	更优方案
基于下标的循环	`.iter()` 、 `.enumerate()`
先 `collect::<Vec<_>>()` 再迭代	链式调用迭代器
手动实现unsafe cell	使用 `Cell` 、 `RefCell`
使用 `mem::transmute` 进行类型转换	使用 `as` 或 `TryFrom`
自定义链表	使用 `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)

无合理理由不得使用
```
.clone()
```
库代码中不得使用
```
.unwrap()
```
不得存在带有不变式的
```
pub
```
字段
可使用迭代器时不得使用下标循环
可使用
```
&str
```
时不得使用
```
String
```
不得忽略
```
#[must_use]
```
警告
使用
```
unsafe
```
时必须添加SAFETY注释
不得存在超长函数（超过50行）

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

场景	参考内容
所有权模式	m01-ownership
错误处理	m06-error-handling
心智模型	m14-mental-model
性能优化	m10-performance