Clean Code （4）：函数长度、抽象层次

一、什么构成一个“好函数”？

编写一个函数并不难，难的是编写一个易读、易维护、易复用的函数。
我们从三个维度来看“好函数”的要素：

1. 调用时可读性强
2. 函数体简洁明确
3. 输出与副作用可控

---

调用函数的可读性：读起来，就像在说人话

函数调用的语义应当尽可能自然。
好的函数命名与参数设计，让函数调用像阅读一段逻辑描述一样顺畅。

✅ 要点

• 参数数量越少越好
• 参数顺序应与语义逻辑一致
• 少用布尔型参数（容易混淆意图）

🔧 示例：

# 糟糕的命名与参数设计
processData(True, 50)

# 良好的命名与参数设计
resizeImage(width=50, keep_aspect=True)

上面的第二种写法更自然，表达意图清晰。

---

函数体的结构：短小而专注

函数的内部实现应当只做一件事（Single Responsibility）。
当函数太长时，逻辑复杂度会指数级增加，重构与测试成本也随之上升。

---

📊 思维导图：影响函数可读性的关键因素

---

一个函数只做一件事

当一个函数试图做太多事情时，它就不再“抽象”，而成为“代码碎片的拼接”。

重构的目标是提高抽象层级一致性：
函数内部的代码应在同一个思维层面上工作。

✅ 建议：

• 若一个函数包含多个逻辑阶段（例如验证 → 计算 → 更新），应尝试拆分成子函数。
• 每个子函数对应一个明确的意图。

---

🌿 示例：糟糕与优化的函数结构对比

# ❌ 糟糕示例：功能混杂
def handleUserData(user):
    if not user.is_valid():
        log.error("Invalid user")
        return None
    db.save(user)
    send_welcome_email(user.email)
    update_statistics()

# ✅ 改进示例：逻辑分层，更好维护
def handleUserData(user):
    if not isUserValid(user):
        logInvalidUser(user)
        return None
    
    persistUserData(user)
    onboardUser(user)
    updateSystemMetrics()

def isUserValid(user): ...
def logInvalidUser(user): ...
def persistUserData(user): ...
def onboardUser(user): ...
def updateSystemMetrics(): ...

这样的结构让每个函数的职责清晰，后续维护更方便。

---

避免重复代码（Don’t Repeat Yourself）

重复代码不仅浪费时间，更容易引入不一致性的错误。
任何发现相似结构的地方，都可以考虑抽象成辅助函数。

---

小心“输出参数”

输出参数容易混淆调用方的意图，也可能改变函数的副作用边界。
如果函数需要返回多个值，建议返回一个对象或元组，而不是通过修改外部变量。

# ❌ 输出参数的陷阱
def fillStats(stats):
    stats['count'] = 20
    stats['avg'] = 4.5

# ✅ 更好的做法
def getStats():
    return {'count': 20, 'avg': 4.5}

这样不仅使函数更“纯净”，也更符合函数式编程的理念。

---

二、函数拆分与抽象层次

“函数拆分”不是简单地把代码分块，而是要建立清晰的抽象边界。
每个函数应位于一个明确的抽象层次上。

---

🪄 抽象层次示意图

例如：

• 高层函数：面向业务逻辑（如处理订单）
• 中层函数：处理数据、验证输入
• 底层函数：执行数据库操作或网络请求

✅ 当你在一个函数中看到不同层次的逻辑时，它就应当被拆分。

---

🔧 拆分流程图

下面是一个函数重构过程的逻辑流程：

---

三、总结与实践指南

维度	建议	目的
参数	控制数量与顺序	提高调用可读性
行数	保持短小	降低复杂度
职责	单一职责原则	易于维护
输出	返回值代替输出参数	消除副作用
抽象	一致的层次结构	更高可读性与复用性

---

最佳实践清单

1. 每个函数都应能被一句话描述其作用。
2. 函数名应揭示意图，而非实现细节。
3. 行数控制在 10~20 行为宜。
4. 避免嵌套超过两层。
5. 使用返回值代替修改外部状态。

---

最后的思考

干净的代码并非“短小即美”，
真正的 Clean Code 是一种思维方式：

每一行函数都在服务于“清晰的意图表达”。