# 命名为何最难：一条代码神课深读 ## 概述 "计算机科学只有两大难题：缓存失效和给东西命名。”这句流传了三十多年的老话，每个程序员都听过，但很少有人认真追问：为什么起个名字能和缓存失效这种硬核技术问题并列？YouTube 频道 CodeAesthetic 的《Naming Things in Code》就是冲着这个问题去的。这支视频用十几分钟、一块白板和几乎零行代码，把“命名”这件人人每天都在做、却没人系统学过的事情讲成了一个工程问题：名字不是标签，是抽象的第一道边界，是你留给三个月后的自己唯一的说明书。本文按视频叙事顺序逐层拆解它背后的真实理论与研究，指出哪些主张证据扎实、哪些只是美丽的传说，并给出三条立刻能用的操作建议。 **说明**：本文写作环境的网络采集工具受限，未能实时抓取 YouTube 数据页，播放量、发布日期等精确数据暂缺，请以参考来源中的频道页面为准；文中涉及的视频内容基于该视频公开发布的信息整理。 ## 视频基本信息 | 项目 | 内容 | |------|------| | 视频标题 | Naming Things in Code（代码里的命名问题） | | 频道 | CodeAesthetic | | 分类 | 编程素养 / 软件工程 | | 发布时间 | 2022 年（据频道页面，未实时核验） | | 播放量 | 未能实时核验，为该频道播放最高的代表作之一 | | 形式 | 动画白板讲解，无真人出镜，约十几分钟 | CodeAesthetic 是近年编程素养类内容里的一匹黑马：不追框架、不炒热点，一支视频只讲一个工程基本功，用极简动画把抽象概念画出来。该频道另一支名作《Why You Shouldn't Nest Your Code》（嵌套代码为什么失控）此前已在本栏目深读过，而《Naming Things in Code》是它的“姊妹篇”——一个管代码的纵向结构，一个管代码的名字系统。 ## 一、开场暴论：两大难题，一件你天天在做 视频开场没有绕弯子，直接把那句“缓存失效和命名”的祖训拍在桌上。但 CodeAesthetic 的讲法有个聪明之处：他没有把这句话当成段子带过，而是当真了——既然命名真的这么难，那它难在哪？ 传统回答是“语言问题”：英语不好，所以名字起不好。视频否定了这个解释。它给出的诊断是：**命名难，不是因为词汇量不够，而是因为命名本质上是在做“抽象”**——你要在还没写出来的代码里，预判这个东西未来会被怎么用、怎么改、被谁读，然后把这个预判压缩进几个单词里。起不出好名字，往往不是语文问题，而是**你还没想清楚这个东西到底是什么**。 这个开场为全片定了调：命名不是编码前的琐事，而是设计行为本身。后面所有规则，都是这个判断的推论。 ## 二、核心主张拆解：四层递进的论证 ### 2.1 第一层：编译器不在乎，只有人在乎 视频的第一个支柱论点，是整个现代软件工程的地基：**代码的主要读者是人，不是机器**。编译器、解释器、虚拟机对变量叫 `d` 还是 `elapsedTimeInDays` 毫无感觉，性能也没有区别——名字在编译后基本消失。但软件的维护期远长于编写期，一个函数平均会被读几十次才被改一次。这意味着“写”是一次性的，“读”是持续性的，任何让读变难的决策都是负资产。 这层论证的巧妙在于它把命名问题从“风格偏好”升格成了“经济学问题”：名字是写入成本低、读取收益极高的投资。花十秒想一个好名字，换的是未来每一次读代码的人少猜十秒——乘以团队人数、乘以代码寿命，杠杆极大。 ### 2.2 第二层：好名字不撒谎 接着视频进入具体规则，而所有规则的第一条是“诚实”：**名字必须准确描述这个东西实际做的事，否则它不是中性信息，而是错误信息**。 视频里最有杀伤力的例子是 `getUser()` 这类方法名。在绝大多数语言的惯例里，`getXxx` 意味着“廉价访问已有数据”，读到这行代码的人会放心地在一个循环里调用它一万次。但如果 `getUser()` 内部偷偷发起了一次数据库查询或网络请求，这个名字就在撒谎——它借用了惯例的信用，却让你为此付出一次 IO 的代价。性能 bug 就这样藏在一个“看起来人畜无害”的名字底下。 由此推出一串细则，每条都能单独拿出来用： - **别用万能词**：`data`、`info`、`temp`、`process`、`handle` 这类词是“我不想想了”的正式声明。它们唯一传达的信息是“这里有个东西”，和没有名字一样。 - **带上单位与语境**：`duration` 和 `durationMs` 是两个名字，前者逼每个读者去翻实现确认单位，后者把答案写在原地。 - **布尔值读成陈述句**：用 `is`、`has`、`can` 前缀，让 `if (isValid)` 读起来像英语句子；避免 `isNotDisabled` 这种双重否定——读者要在脑内做一次布尔代数才能通过。 - **缩写是可读性税**：`usrAddrCnt` 省下的是打字的时间，征收的是每个读者解码的时间，而且这笔税永久征收。除非是领域内的通用语（URL、ID、HTML），否则别用。 ### 2.3 第三层：名字的长度应该与作用域成正比 这一条是视频里最反直觉、也最能体现工程判断力的规则：**短名字不是罪，长名字也不是美德，关键是匹配可见范围**。 三行循环里的下标 `i` 是完美的名字——它的作用域只有三行，读者视线不移开就能看到它的全部生命周期，此时写 `loopIndex` 反而是噪音。反过来，一个会被散布到二十个文件里的类型，名字就必须长到自带解释，因为读者遇到它时，上下文可能只有那一行。 这条规则背后的原则是：**读者解码名字的成本，取决于离定义有多远**。命名不是全局统一的长或短，而是按“读者需要跳转几次才能搞明白”来定价。这也是为什么许多团队规范里“单字母变量只允许出现在小作用域”成了铁律——它不是审美，是成本核算。 ### 2.4 第四层：起不出名字，说明抽象没想清 视频的后半段完成了一次升维：命名难的真正原因，往往不在语言层，而在设计层。 一个东西如果有清晰的职责，名字几乎会自己浮现：它做的事只有一种，用一句话说出来，压缩一下就是名字。而当你对着一个类纠结半小时、在 `Manager`、`Helper`、`Utils` 之间来回摇摆时，卡住的通常不是词汇——是这个“东西”本身职责不清，它什么都干一点，所以什么都叫不出来。**命名困难是设计坏味道的免费探测器**：名字起不顺，就回去重新切分职责，而不是硬起一个 `Manager` 了事。 这也解释了为什么视频把“一致性”单拎出来强调：同一个概念，在代码库里一会儿叫 `fetchUser`、一会儿叫 `getUserById`、一会儿叫 `loadUserInfo`，读者会误以为三个名字对应三种不同的行为，花时间去寻找并不存在的区别。好命名体系像一门语言——词汇不必多，但每个词只有一个意思，每个意思只有一个词。 ## 三、知识与理论溯源：视频背后站着谁 CodeAesthetic 的视频没有引文列表，但它的每个论点在真实文献里都有出处。这一节把它们接回去。 **Donald Knuth 与文学编程（1984）**。“程序首先是写给人读的，只是顺带能在机器上执行”——这句名言出自 Knuth 1984 年在《The Computer Journal》上的《Literate Programming》一文。Knuth 主张把程序当作面向人的文学作品来写，这个思想直接奠定了“可读性优先”的现代共识，也是视频中“编译器不在乎”论点的学术源头。 **工作记忆容量研究**。为什么缩写和双重否定伤人？认知科学给出的答案是：人的工作记忆容量极其有限。George Miller 1956 年的经典论文《The Magical Number Seven, Plus or Minus Two》估计瞬时记忆约七个组块；后续研究（如 Cowan 2001）把这个数字修正到四左右。每个晦涩缩写都要占用一个“解码槽”，读代码的注意力预算就这么多，花在猜名字上的，就是花在理解逻辑上少掉的。 **标识符风格的眼动实验**。命名影响理解速度不只是经验之谈。Sharif 与 Maletic 在 2010 年发表的眼动追踪研究比较了 camelCase 与 snake_case 风格，结果显示开发者在识别 camelCase 风格标识符时平均用时更短、准确率略高——尽管差异幅度存在争议，但“命名风格 measurable 地影响理解成本”这件事进入了实证领域。（注：该研究样本规模较小，结论应视为方向性证据而非定论。） **《Clean Code》（Robert C. Martin, 2008）**。视频中的多条细则——万能词禁忌、`get` 前缀的惯例含义、布尔命名法——都能在《Clean Code》第二章 "Meaningful Names" 里找到对应，Martin 把命名列为了解代码的第一道门槛。 **《Code Complete》（Steve McConnell, 2004）**。第二版用整章篇幅讨论变量命名，包括“名字长度与作用域相关”的经验数据，是视频中第三层主张的直接出处。 **领域驱动设计（Eric Evans, 2003）**。“起不出名字说明抽象没想清”与 DDD 的核心主张同构：Evans 强调团队要建立 "Ubiquitous Language"（统一语言），让代码里的术语和业务专家嘴里的术语一一对应。命名不是程序员的私事，是业务建模的一部分。 ## 四、批判性审查：哪些可信，哪些要打折 **“两大难题”格言：真实性高，出处存疑**。这句话通常归于 Netscape 早期工程师 Phil Karlton，但它只有口头传播史，找不到原始书面文献，Karlton 本人的原话版本也和流传版有出入。把它当文化梗引用没问题，当文献引用不行——这也算一次绝佳的示范：连“关于命名的名言”都需要被命名核实。 **Clean Code 的性能争议**。视频大体继承了 Clean Code 的命名观，但要补一个重要背景：Martin 的整套主张近年来遭到了严肃反驳。游戏引擎工程师 Casey Muratori 2023 年的长文《"Clean" Code, Horrible Performance》用可复现的基准测试指出，Clean Code 推崇的部分实践（包括过度拆分和抽象层堆叠）在性能敏感场景下代价巨大，某些基准里性能差了一个数量级。对命名的启示是：规则的适用场景很重要——业务代码里，可读性几乎永远赢；但在每纳秒都算数的热循环里，为“诚实”付出的间接层调用可能需要重新讨价还价。 **规则不是法律**。视频给出的规则都好用，但存在合理例外：数学代码里的 `x`、`n`、`f(x)` 是领域惯用法，强行改成 `inputValue` 反而伤害了与教科书的互认；游戏行业 60FPS 战线上 `tmp` 缓冲区的短命名字也有其局部合理性。判断标准始终是视频那条主线——读者的解码成本——而不是规则本身。 **一个视频没有覆盖的盲区**：命名与注释的关系。代码自注释运动有时被推到极端，变成“好代码不需要注释”的教条。现实是，名字能承载的是“这是什么”，而“为什么不这样做”（为什么这里偏不用标准算法、为什么有这个奇怪的例外）永远放不进名字里。命名解决一半沟通，另一半需要注释诚实补位。视频没谈这层，读者别自己补成教条。 **AI 时代的反向杠杆**（这是延伸判断，非视频内容）：大模型辅助编程让命名的价值不降反升。LLM 生成的质量高度依赖上下文语义——一个叫 `processData` 的函数给不出任何生成线索，而 `dedupeOrdersByCustomer` 能让模型和人类读者获得同样精确的意图锚点。你起的名字，现在同时是给同事的说明书和给 AI 的提示词。 ## 五、认知提升与实用启示 **1. 用“注释先行法”倒逼好名字**。写新函数时，先不写代码，先用一句普通中文描述它做什么，比如“把过期的订阅标记为失效并发通知”。这句话里的动词和名词就是函数名和参数名的候选，压不掉的部分就是它真正的职责，而如果这句话本身要说三行——恭喜，你的抽象需要拆分，问题被命名探测器提前抓住了。 **2. 建一张十行的团队词汇表**。不必搞重型 DDD 流程，开一个共享文档，把项目里最高频的十个业务概念钉死：每个概念一个动词（取数据是 `get` 还是 `fetch`？失效是 `expire` 还是 `invalidate`？），一次决议，全库生效。命名的内耗大多来自“每个新人都重新发明一遍同义词”，一张十行表就能终结这场内战。 **3. 把重命名当成最便宜的重构**。现代 IDE 的一键改名让“起错了再改”的成本趋近于零，所以别追求一次到位——名字和代码一样是迭代出来的，写代码途中发现更好的名字就立刻改，code review 时把“这个名字会让读者误会什么”单列为一个审查项。最贵的不是改名的十分钟，而是让一个撒谎的名字在代码库里活三年。 ## 视频论证结构 ```mermaid flowchart TD A[祖训:命名是两大难题之一] --> B[诊断:难在抽象
不是难在词汇] B --> C[支柱:代码写给人读
编译器不在乎] C --> D[规则一:名字不撒谎
getUser不得偷做IO] C --> E[规则二:长度匹配作用域
短名只进小作用域] C --> F[规则三:一词一义
全库同概念同词] D --> G[探测器:起不出名字
说明职责没想清] E --> G F --> G G --> H[结论:命名即建模
改名是重构第一步] ``` ## 延伸阅读 1. **CodeAesthetic《Abstraction Can Make or Break Your Project》**——同一频道的抽象主题视频，与本篇构成上下篇：命名管词汇，抽象管结构，二者合起来才是完整的“代码可读性经济学”。 2. **《The Art of Readable Code》**（Dustin Boswell & Trevor Foucher, O'Reilly）——把视频里的命名规则放回完整代码可读性框架中，含大量正反对照实例，适合作为视频的“文字版练习册”。 ## 参考来源 > 说明：本次写作环境网络采集工具受限，未能实时抓取视频数据页；以下均为稳定公开入口，精确播放数据请以频道页面为准。 1. [CodeAesthetic 频道页](https://www.youtube.com/@CodeAesthetic) — 视频《Naming Things in Code》所在频道主页 2. [YouTube 站内搜索：Naming Things in Code CodeAesthetic](https://www.youtube.com/results?search_query=CodeAesthetic+Naming+Things+in+Code) — 直达该视频的检索入口 3. [Literate Programming - Wikipedia](https://en.wikipedia.org/wiki/Literate_programming) — Knuth 1984 年文学编程思想与“程序写给人读”名言出处 4. [Computer Enhance（Casey Muratori）](https://www.computerenhance.com/) — 《"Clean" Code, Horrible Performance》发表地，Clean Code 性能争议的一手来源 5. [Naming convention (programming) - Wikipedia](https://en.wikipedia.org/wiki/Naming_convention_(programming)) — 各语言命名惯例与 camelCase/snake_case 背景知识 --- > 本文由「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 等场景全覆盖。