# 命名神课深读：代码里最难的两个字 ## 概述 在编程与开发这个分类里，讲算法、讲框架、讲架构的视频汗牛充栋，但有一支视频专门死磕一个所有工程师每天都在做、却几乎没人系统学过的事：**给变量和函数起名字**。CodeAesthetic 的《Naming Things in Code》用不到十分钟的动画，把"命名"从一件被当成琐事的小事，讲成了理解代码质量的入口——为什么坏名字会主动骗人、好名字的五条产生规则、以及"取不出名字"这个信号如何在提示你的设计出了问题。本文按视频的叙事顺序逐点拆解，补上它背后的理论出处与实证研究，也指出它哪些话说得比证据更满。没看过视频，你可以完整吸收它的论证；看过视频，你会知道它每个观点在软件工程文献里的祖籍在哪里。 ## 视频基本信息 | 项目 | 内容 | |------|------| | 视频标题 | Naming Things in Code（直译：《代码中的命名》） | | 频道 | CodeAesthetic | | 发布时间 | 2021年（据频道页面；具体日期未实时核实） | | 播放量 | 400万以上量级（据频道页面及多方转引，未经实时核实） | | 时长 | 约10分钟（据频道页面） | | 形式 | 动画演示 + 代码对比，无真人出镜 | > 说明：本篇成稿时未能实时抓取视频页，以上数据为据频道页面与公开引用整理，精确数字请以视频页为准。频道以短小精悍的软件设计动画闻名，多支视频播放量达数百万，这支是其中被引用最多的一支。 ## 一、视频讲了什么：论证主线拆解 ### 1. 开场破题：你每天都在做"最难的事" 视频从软件圈那句流传最广的老梗开场："计算机科学里只有两件难事：缓存失效和命名。"（后面还跟着第三个笑话：差一错误。）这句话常被当作段子转发，但视频认真对待了它：缓存失效再难，多数工程师一周也遇不到几次；而命名是每个工程师每小时都在做的动作。**使用频率最高的难题，恰恰是教学中着墨最少的难题**——这是全片立论的起点。 ### 2. 为什么名字是"最重要的文档" 第二步论证转移到了"代码到底写给谁看"。视频的答案继承自软件工程的经典立场：代码主要写给人读，只是顺带让机器执行。基于此，它给名字一个极高的定位——名字是你密度最高的文档。理由是：注释写完就死了，代码改动时注释经常被遗忘，慢慢从"文档"腐烂成"谣言"；而名字不同，每一次调用都必须与定义对齐，编译器（或至少是测试与调用方）会强制所有使用处跟它保持一致。所以在视频的框架里：**注释是低维护成本的补充说明，名字是唯一被强制保持新鲜的文档**。 ### 3. 坏名字不是"没帮忙"，是"在骗人" 接下来是一组反面案例，也是全片最有共鸣的段落。`data`、`temp`、`info`、`result`、`manager`、`utils`——这些词的共同问题是：**它们描述的信息量为零**。一个叫 `processData()` 的函数，等于在门口挂了块牌子写"这里在干活"。视频进一步指出更危险的一类：撒谎的名字。如果一个函数叫 `getUsers()`，实际却顺手写了数据库，那么每个读代码的人都会在它面前放下戒心——坏名字不只是浪费读者时间，它会给错误行为盖"检查通过"的章。另一个被点名的反面教材是把类型编码进名字的"匈牙利记号"用法：`strName`、`intCount` 这类名字，把本该由类型系统管的账本，强行塞进人脑的记忆里。 ### 4. 五条可执行的命名规则 论证铺垫完，视频给出正面清单，这也是它被反复收藏的原因——每一条都能在下次写代码时直接用： - **写用途，不写类型**：名字回答"它是干什么的"，不回答"它是什么数据结构"。`overdueCustomers` 优于 `customerArray`；类型信息交给类型系统，语义信息才归名字管。 - **把单位和约束写进名字**：`delayMs`、`heightInMeters`、`maxRetryCount`。单位混用是真实世界的事故源，名字是防线的第一道。 - **布尔名读成肯定问句**：`isActive`、`hasLicense` 让 `if` 语句读起来像英语句子；反过来 `isNotDisabled` 这种双重否定，是每读一次都要心算一次的税。 - **作用域越长，名字越长**：三行循环里的 `i` 无罪；但一个被十几个文件使用的字段，配得上一个自解释的长名。名字长度应该和读者离它的"认知距离"成正比。 - **一词一义，说行业的语言**：`get`、`fetch`、`retrieve` 选一个用到底；同一个词不能既指"订单"又指"会话"。更进一步，名字应该跟领域专家嘴里说的一致——用户说"保单"你就别叫"合同对象"。 ### 5. 收尾升华：取名困难是设计警报 视频的结尾把话题从"技巧"抬到"设计"：如果你给一个模块取名时反复纠结、怎么取都别扭，问题多半不在词汇量，而在**这个模块本身职责不清**——它可能干了两件事，或者根本不该存在。命名不是给现成的东西贴标签，而是给概念划边界的手段；取名的过程，就是你逼自己想清楚"它到底是什么"的过程。最后的号召很朴素：为名字多花一分钟，未来读代码的人——包括几个月后的你自己——会感谢现在的你。 ## 二、知识与理论溯源 这支视频没有直接给参考文献，但它的每个论点在软件工程文献里都有明确的祖籍，这是"看过视频还能多懂一层"的部分。 **"两件难事"这句话确实有出处**。它通常被归于网景公司（Netscape）首席工程师 Phil Karlton，经 Martin Fowler 在博客里引用考据后广泛传播。Fowler 还补充了后半句的常见变体"……和 off-by-one errors"，并指出这句话流行的原因：它是少数让所有程序员都会心一笑的"真话"。 **"代码写给人读"的立场来自 SICP**。Abelson 与 Sussman 在《计算机程序的构造和解释》（SICP，1985）序言里写下那句名言："程序是写给人读的，只是顺便让机器执行。"这句话是整支视频世界观的源头——先接受"读者是人"，"名字是最重要的界面"才成立。 **"写用途不写类型"在《代码整洁之道》里有整整一章**。Robert C. Martin 在《Clean Code》（2008）第二章"Meaningful Names"里系统列过几乎相同的清单：名字要 revealing intent（显露意图）、要避免 disinformation（误导）、要做可搜索的名字（所以反对单字母名用于大作用域）、一个概念一个词。视频的规则清单基本是这一章的动画精编版。更早的 Steve McConnell《代码大全》（Code Complete）第十一章"变量名的力量"也讲过同一套：名字的首要任务是表达"这个变量在问题域里代表什么"。 **"说行业的语言"来自领域驱动设计**。Eric Evans 在《Domain-Driven Design》（2003）里提出"统一语言"（Ubiquitous Language）：代码中的术语应与业务专家使用的语言严格一致，翻译层（业务说A、代码叫B）是缺陷的温床。视频把这条从企业级架构方法论下放到了"给变量起名"这个最小尺度。 **"作用域越长名字越长"也是成文的工程规范**。Clean Code 与 Boswell、Foucher 的《The Art of Readable Code》（2011）都明确表述过这条规则，后者甚至给出了类似的比喻：局部变量的名字像便签，全局名字像门牌。 **"匈牙利记号"的挨打有历史原因**。这套命名法由 Charles Simonyi（施乐帕克研究中心出身，后加入微软）发明，本意是"应用匈牙利"——把**语义**信息编进名字（比如"这是屏幕坐标还是纸面坐标"），这在缺乏类型检查的年代确有价值；后来在微软被异化成"系统匈牙利"——把**类型**信息编进名字（`str`、`int` 前缀），变成了纯粹的人肉冗余。视频批评的是后者。Joel Spolsky 2005 年那篇《Making Wrong Code Look Wrong》对这段公案有最清晰的梳理：同一套记号，用来编码语义是护身符，用来编码类型是负担。 **"单位写进名字"背后有真实事故**。1999 年 NASA 火星气候探测器（Mars Climate Orbiter）在火星大气中解体，事故调查报告认定直接原因之一：地面软件提供的是磅力·秒，而探测器软件期望的是牛·秒——单位错了，代码照常运行。这艘探测器价值约1.25亿美元。如果推力变量的名字里带着单位，这个 bug 在 review 时读得出来。 **"取名困难是设计警报"来自 John Ousterhout**。斯坦福教授、《A Philosophy of Software Design》（2018）作者在书中明确表述过这个判断：如果一个抽象很难找到简洁准确的名字，通常不是词汇问题，而是抽象本身设计得不好——先重新切分，再回来取名。 ## 三、批判性审查：哪些站得住，哪些说过头 ### 证据充分的部分 命名影响代码质量，并非只有经验之谈。学术侧有实证研究支持：Fakhoury 等人在 ESEC/FSE 2018 发表的实证研究发现，源代码词汇质量差（标识符含义不清、命名不一致）会显著提高开发者的认知负荷、拉长理解时间（据 ACM 数字图书馆收录论文）。更早的 Binkley 等人研究过标识符风格（camelCase 与下划线），发现命名风格对阅读效率确实存在可测量的影响——尽管效应量小、且受程序员训练背景调节（据 ICPC 会议论文，2009）。另外，"误导性名字比平庸名字更糟"这一点在工程界近乎共识：中性名字只是不帮忙，撒谎的名字会把 bug 藏进 review 的盲区。视频在这条线上是稳健的。 ### 说过头或有争议的部分 **第一，"名字是不会过期的文档"被夸大了。** 名字与定义的强制对齐只在理想条件下成立：静态类型、重命名工具能追到所有引用、没有基于字符串的反射与序列化、公共 API 不被兼容性冻结。现实里这四个条件经常缺一两个——动态语言里改了名字没改调用处、接口冻结导致 `getUsers` 早已不"get"，都让名字撒谎的能力不逊于注释。而且注释能承载一类名字结构上装不下的信息：**"为什么这样写"的权衡**（为什么这里要睡眠500毫秒、为什么不用更直观的方案）。Knuth 的"文学编程"传统恰恰强调这种设计意图的记录。名字和注释是互补的文档，不是替代关系。 **第二，"多花时间命名"要防琐碎定律反噬。** C. Northcote Parkinson 在1955年提出的"琐碎定律"（Law of Triviality）指出：组织讨论的时间分配与议题重要性成反比——因为人人都敢对自行车棚发表意见。命名恰好是代码里最"自行车棚"的东西：人人都能评论，人人都不需要理解全局。团队完全可能在函数名上吵掉一小时，而没人看那处真正的竞态条件。视频号召个人多花一分钟没问题，但把它上升为团队规范时，需要配套机制（命名检查清单、术语表）把它约束在低成本区间，否则容易变成品味内耗。 **第三，实证证据的强度跟不上视频的语气。** 命名研究的样本普遍偏小、被试多为学生，效应量中等偏弱；"好名字能提升X%生产力"这种精确结论，文献里并不存在。视频的笃定语气是传播技巧，不是证据强度。对个人实践，这套建议的置信度很高（成本极低、几乎无下行风险）；对团队，更稳妥的姿态是把它当默认偏好而非铁律——数学密集的代码贴近论文符号用短名（`i`、`j`、`dx`）反而正确，这一点连视频自己的"作用域规则"都容纳。 总体评价：这支视频的论证方向在工程文献里有深厚支撑，夸大的只有"名字永不腐烂"这类修辞性的绝对化表述。它最经得起检验的部分，恰恰是那五条规则——因为每一条的成本几乎为零，而下行风险几乎不存在。 ## 四、给工程师的三条实操建议 **1. 给团队建一份"禁词表 + 术语表"，让命名审查可执行。** 禁词表列出本仓库禁用的零信息词（`data`、`temp`、`info`、`handle`、`process`、`manager`、`utils`……），review 时像 lint 一样机械检查；术语表则为核心业务概念规定唯一英文词（"保单"永远叫 `policy`，不许 `contract` 出现）。这把"品味之争"变成"对表执行"，正是琐碎定律的解毒剂。 **2. 把"取名困难"当设计警报，练习"重命名驱动设计"。** 下次给一个类或函数取名超过三分钟还别扭，别硬憋——按 Ousterhout 的路径走：先怀疑切分。试着把它拆成两半各取一名，或者合并进别处。取不出名 = 概念边界不清；名字取顺了，往往说明设计想通了。重命名工具便宜的今天，rename 是成本最低的"设计验证器"。 **3. 让名字替你抓 bug：单位、约束、肯定式布尔。** 从今天起新写的每个数值变量带单位（`timeoutMs`、`diskGigabytes`），每个布尔是肯定问句（`isSettled` 而非 `notFailed`），缓存、默认值、上限这类约束进名字（`cachedUser`、`defaultLocale`、`maxRetries`）。这是火星气候探测器用1.25亿美元换来的教训的最低成本版本：让撒谎的代码在 review 时读起来不对劲。 ## 五、视频论证结构图 ```mermaid flowchart TD A[命名难题开场
最高频的两难] --> B[代码写给人读
读远多于写] B --> C[名字是最重要的
活文档] C --> D[反例
零信息词与撒谎名] D --> E[写用途不写类型] D --> F[名字带单位约束] D --> G[布尔读成问句] D --> H[作用域定长度] D --> I[一词一义说行话] E --> J[取名困难
是设计警报] F --> J G --> J H --> J I --> J J --> K[重命名驱动理解
可维护性上升] ``` ## 延伸阅读 1. **John Ousterhout《A Philosophy of Software Design》（2018）** — "取名困难是设计警报"这条最有洞察的观点，书中用整章展开"什么样的抽象是好抽象"，是这支视频结尾的自然下一步。 2. **Martin Fowler，"TwoHardThings"** — 对"计算机科学只有两件难事"这句名言的出处考据与引申，适合想追根溯源的读者。 ## 参考来源 1. [Naming Things in Code — CodeAesthetic（YouTube）](https://www.youtube.com/watch?v=FyCYva9DhsI) — 本文解读的原视频，播放量与发布时间据频道页面 2. [Martin Fowler: TwoHardThings](https://martinfowler.com/bliki/TwoHardThings.html) — "两件难事"名言的出处考据 3. [Wikipedia: Clean Code](https://en.wikipedia.org/wiki/Clean_Code) — Robert C. Martin 著作背景，第二章"Meaningful Names"为视频规则清单的主要蓝本 4. [Wikipedia: Mars Climate Orbiter](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) — 1999年单位混用事故，"单位写进名字"的实证案例 5. [Wikipedia: Domain-driven design](https://en.wikipedia.org/wiki/Domain-driven_design) — Eric Evans"统一语言"概念，"说行业的语言"这条规则的理论源头 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。