第 14 章：命名
系列：软件设计的哲学 · 第 14/22 章
全书导读：00-overview.md
一句话总结
好名字是活的注释——精确、一致、有信息量的命名直接降低认知负荷，让深模块的接口真正「看起来简单」。
核心观点浓缩
- 命名目标：读者第一次见名就猜对用途与类型，少查定义、少误用
- 精确优于短：
elapsedMs好过time；removeFromQueue好过remove - 一致：同一概念全库同一词（fetch/get/load 勿混用）；同类 API 同模式
- 模块/类名表抽象层级；方法名表动作 + 对象；布尔用
is/has/can - 好命名减少注释需求，但不能替代接口注释中的契约与边界说明
- 长度与作用域成正比：局部循环
i可短；跨文件类型名应完整到可搜索 - 重构时先改名再改逻辑，让编译器与审阅者共同充当安全检查
- 避免同义不同名：同一业务实体在 UI、Service、DB 层应用同一词根
- 枚举值名应可读作完整短语，而非
TYPE_3式 mystery meat
关键概念 / 金句
| 反模式 | 改进 |
|---|---|
data, info, manager | 具体域名词：ScanFrame, MeshCache |
process(), handle() | 动词 + 宾语：fusePointClouds() |
缩写各写各的 cfg/conf/config | 团队词典定一种 |
「若你需要注释解释变量含义，多半名字起错了。」
本章在全书中的位置
第 14 章与第 12–13 章注释、第 18 章「显而易见」同属可读性工具链。命名在源码层传递语义；注释在设计层补全代码无法承载的信息。二者叠加才让第 4 章的深模块接口可读。Ousterhout 强调：命名是最低摩擦的可读性投资——改名的成本远低于改架构，却常能立刻降低调用方的理解负担。
个人思考与启发
把 FITMeServiceRequest 里泛化的 doRequest(type, payload) 拆成 uploadMesh()、pollTaskStatus() 后，调用处分支减半，Code Review 不再反复问 type 枚举含义。改名是最低成本的接口简化。Qt 信号槽若统一 signalXxxChanged / slotOnXxx，全局搜索连接关系时不必猜命名变体，这是命名一致性的日常收益。域术语与产品文档对齐后，跨职能沟通也省解释成本。IDE 全局 rename 是本书原则最可落地的日常操作之一。
与《程序员修炼之道》对照
- 无处不在的自动化含命名约定；本书强调名字承载设计信息
- 「解谜式命名」是技术债；与「让代码 obvious」一脉相承
- 元数据/配置键命名同样适用——泄漏到 UI 层的键名也是 API
- 可逆性要求名字反映当前意图；历史别名应通过 typedef/using 集中而非并存
重点与注意
重点：新名字应能独立成句——「X 做了 Y」读得通。
重点：重命名是降低复杂度的有效重构，别怕大范围 rename（IDE 辅助）。
注意：勿为省字符牺牲精度；磁盘与屏幕不是瓶颈，理解才是。
注意：与第 17 章一致性联动——项目应有命名词表（中英域术语对照亦可）。
注意：公开 API 改名视为破坏性变更，需版本说明与迁移注释。
注意：缩写仅允许词表内条目；新缩写须先写入团队命名词表再使用。
导航：第 13 章 注释写什么 · 下一篇：第 15 章 先写注释