"计算机科学只有两大难题：缓存失效和给东西命名。”这句流传了三十多年的老话，每个程序员都听过，但很少有人认真追问：为什么起个名字能和缓存失效这种硬核技术问题并列？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 的讲法有个聪明之处：他没有把这句话当成段子带过，而是当真了——既然命名真的这么难，那它难在哪？
传统回答是“语言问题”：英语不好，所以名字起不好。视频否定了这个解释。它给出的诊断是：命名难，不是因为词汇量不够，而是因为命名本质上是在做“抽象”——你要在还没写出来的代码里，预判这个东西未来会被怎么用、怎么改、被谁读，然后把这个预判压缩进几个单词里。起不出好名字，往往不是语文问题，而是你还没想清楚这个东西到底是什么。
这个开场为全片定了调：命名不是编码前的琐事，而是设计行为本身。后面所有规则，都是这个判断的推论。
视频的第一个支柱论点，是整个现代软件工程的地基：代码的主要读者是人，不是机器。编译器、解释器、虚拟机对变量叫 d 还是 elapsedTimeInDays 毫无感觉，性能也没有区别——名字在编译后基本消失。但软件的维护期远长于编写期，一个函数平均会被读几十次才被改一次。这意味着“写”是一次性的，“读”是持续性的，任何让读变难的决策都是负资产。
这层论证的巧妙在于它把命名问题从“风格偏好”升格成了“经济学问题”：名字是写入成本低、读取收益极高的投资。花十秒想一个好名字，换的是未来每一次读代码的人少猜十秒——乘以团队人数、乘以代码寿命，杠杆极大。
接着视频进入具体规则，而所有规则的第一条是“诚实”：名字必须准确描述这个东西实际做的事，否则它不是中性信息，而是错误信息。
视频里最有杀伤力的例子是 getUser() 这类方法名。在绝大多数语言的惯例里，getXxx 意味着“廉价访问已有数据”，读到这行代码的人会放心地在一个循环里调用它一万次。但如果 getUser() 内部偷偷发起了一次数据库查询或网络请求，这个名字就在撒谎——它借用了惯例的信用，却让你为此付出一次 IO 的代价。性能 bug 就这样藏在一个“看起来人畜无害”的名字底下。
由此推出一串细则，每条都能单独拿出来用：
data、info、temp、process、handle 这类词是“我不想想了”的正式声明。它们唯一传达的信息是“这里有个东西”，和没有名字一样。duration 和 durationMs 是两个名字，前者逼每个读者去翻实现确认单位，后者把答案写在原地。is、has、can 前缀，让 if (isValid) 读起来像英语句子；避免 isNotDisabled 这种双重否定——读者要在脑内做一次布尔代数才能通过。usrAddrCnt 省下的是打字的时间，征收的是每个读者解码的时间，而且这笔税永久征收。除非是领域内的通用语（URL、ID、HTML），否则别用。这一条是视频里最反直觉、也最能体现工程判断力的规则：短名字不是罪，长名字也不是美德，关键是匹配可见范围。
三行循环里的下标 i 是完美的名字——它的作用域只有三行，读者视线不移开就能看到它的全部生命周期，此时写 loopIndex 反而是噪音。反过来，一个会被散布到二十个文件里的类型，名字就必须长到自带解释，因为读者遇到它时，上下文可能只有那一行。
这条规则背后的原则是：读者解码名字的成本，取决于离定义有多远。命名不是全局统一的长或短，而是按“读者需要跳转几次才能搞明白”来定价。这也是为什么许多团队规范里“单字母变量只允许出现在小作用域”成了铁律——它不是审美，是成本核算。
视频的后半段完成了一次升维：命名难的真正原因，往往不在语言层，而在设计层。
一个东西如果有清晰的职责，名字几乎会自己浮现：它做的事只有一种，用一句话说出来，压缩一下就是名字。而当你对着一个类纠结半小时、在 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 时把“这个名字会让读者误会什么”单列为一个审查项。最贵的不是改名的十分钟，而是让一个撒谎的名字在代码库里活三年。
flowchart TD
A[祖训:命名是两大难题之一] --> B[诊断:难在抽象<br/>不是难在词汇]
B --> C[支柱:代码写给人读<br/>编译器不在乎]
C --> D[规则一:名字不撒谎<br/>getUser不得偷做IO]
C --> E[规则二:长度匹配作用域<br/>短名只进小作用域]
C --> F[规则三:一词一义<br/>全库同概念同词]
D --> G[探测器:起不出名字<br/>说明职责没想清]
E --> G
F --> G
G --> H[结论:命名即建模<br/>改名是重构第一步]
说明：本次写作环境网络采集工具受限，未能实时抓取视频数据页；以下均为稳定公开入口，精确播放数据请以频道页面为准。
本文由「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 等场景全覆盖。