关联知识库：# Linus Torvalds vs. 模糊抽象：代码命名清晰性与认知负荷的工程思维
Linus Torvalds vs. 模糊抽象：代码命名清晰性与认知负荷的工程思维
原文链接
Linus Torvalds vs. Ambiguous Abstractions（2025年11月26日）
导读概览
2025年8月，Linux内核维护者Linus Torvalds在一个Pull Request中激烈批评了一个看似无害的helper函数。这个案例揭示了代码设计中的一个关键问题：不是所有抽象都是有益的，模糊的抽象实际上会增加认知负荷，让代码变得更难理解。
文章通过分析Linus对make_u32_from_two_u16(hi, lo)这个宏的批评，探讨了代码命名的清晰性原则，以及如何设计真正降低认知负荷的抽象。
案例：Linus的激烈批评
问题代码
/*** make_u32_from_two_u16 - return u32 number by combining* two u16 numbers.* @hi: upper 16 bit number* @lo: lower 16 bit number*/
#define make_u32_from_two_u16(hi, lo) (((u32)(hi) << 16) | (u32)(lo))
Linus的观点
"If you write the code out as
(a << 16) + b, you know what it does and which is the high word. In contrast, if you writemake_u32_from_two_u16(a,b)you have not a f^%$ing clue what the word order is. IOW, you just made things WORSE."
核心问题
- ❌ 参数顺序不明确：从函数名无法判断哪个参数是高位，哪个是低位
- ❌ 需要查看实现：调用者必须打开宏定义才能理解参数顺序
- ❌ 增加认知负荷：抽象不但没有简化，反而增加了理解成本
核心观点提炼
1️⃣ 抽象的双刃剑
"抽象不是免费的，模糊的抽象反而会增加认知负荷"
- 好抽象的特征：名字能清晰传达意图，无需查看实现
- 坏抽象的特征：名字模糊，必须查看实现才能理解
- 判断标准：是否能从调用处直接理解代码含义
2️⃣ 认知负荷的本质
- 人类认知限制：工作记忆只能同时处理4-7个"块"（chunks）
- 抽象的成本：每个抽象都会占用一个"块"的位置
- 模糊抽象的问题：占用"块"的同时，还需要额外加载实现细节
3️⃣ 命名清晰性的重要性
- 自解释代码：好代码应该从名字就能看出意图
- 参数顺序编码：关键信息应该编码在名字中
- 降低理解成本：清晰的命名让代码一目了然
解决方案：清晰的抽象
改进建议
将参数顺序编码到函数名中：
/*** make_u32_from_msw_lsw - return u32 number by combining* two u16 numbers in msw:lsw word order.* @msw: upper 16 bit number (most significant word)* @lsw: lower 16 bit number (least significant word)*/
#define make_u32_from_msw_lsw(msw, lsw) (((u32)(msw) << 16) | (u32)(lsw))
为什么这样更好？
- ✅ 意图清晰：从名字就能看出参数顺序（MSW在前，LSW在后）
- ✅ 无需查看实现：调用处就能理解代码含义
- ✅ 降低认知负荷：不会占用额外的"块"去记忆参数顺序
调用示例对比
// 模糊抽象：需要查看定义才知道顺序
u32 v = make_u32_from_two_u16(0xABCD, 0x1234);// 清晰抽象：从名字就能看出顺序
u32 v = make_u32_from_msw_lsw(0xABCD, 0x1234);
深度思考与启发
1️⃣ 关于抽象的误解
很多人认为"抽象总是好的"，但Linus的案例提醒我们：模糊的抽象比没有抽象更糟糕。如果抽象不能降低认知负荷，反而需要调用者去查看实现，那这个抽象就是失败的。
2️⃣ 认知负荷的权衡
文章作者提到，Linus的主要观点不是"抽象会占用chunk slot"，而是这个抽象本身是错误的抽象。正确的抽象应该清晰到不需要额外的认知成本。
3️⃣ 命名的力量
这个案例完美展示了命名是代码设计的一部分。好的命名能让代码自解释，坏的命名则让代码变得更难理解。当关键信息（如参数顺序）应该被编码到名字中时，就不要依赖注释或实现细节。
4️⃣ 简单直接的代码
Linus建议直接写(a << 16) + b这样的表达式，虽然可能需要类型转换，但至少一目了然。这呼应了"认知负荷"文章中的观点：有时候最简单的代码就是最好的代码。
实践建议
设计抽象时
- 命名检查：从名字能直接理解抽象的作用吗？
- 参数顺序：如果顺序重要，是否编码在名字中？
- 关键信息：调用者需要的关键信息是否在名字中？
- 认知测试：不看实现，能否理解调用处的代码？
️ 命名原则
- 自解释：名字应该说明"做什么"，而不是"怎么做"
- 关键信息编码：将重要的顺序、类型、约束编码到名字中
- 避免模糊词：
hi/lo、a/b这样的名字不够清晰 - 使用专业术语：
MSW/LSW（Most/Least Significant Word）是标准术语
抽象评估
- 是否降低了认知负荷？ 如果答案是否定的，重新考虑抽象
- 是否需要查看实现？ 如果需要，抽象可能不够清晰
- 参数是否有顺序要求？ 如果有，必须在名字中体现
- 是否比直接代码更清晰？ 如果不，直接写代码可能更好
总结
Linus Torvalds的这个案例告诉我们：
- 模糊的抽象是敌人：它们看起来简化了代码，实际上增加了理解成本
- 命名是设计的一部分：好的命名能让抽象清晰，坏的命名让抽象模糊
- 清晰优于简洁：
make_u32_from_msw_lsw比make_u32_from_two_u16长，但更清晰 - 认知负荷是核心：所有代码设计都应该以降低认知负荷为目标
正如文章作者所说："If we want to optimize for cognitive load, there's not necessarily an issue with using helper functions. But if we do, we should make the abstraction as explicit as possible, and that starts with a clear function name that conveys what it tries to accomplish."
核心洞察：不是抽象本身有问题，而是模糊的抽象有问题。好的抽象让意图从名字就能看出，坏的抽象需要打开定义才能理解。当设计抽象时，问问自己：这个抽象会让代码更容易理解，还是更难理解？
本文档基于 The Coder Cafe 的《Linus Torvalds vs. Ambiguous Abstractions》整理，原文作者为 Teiva Harsanyi