在编程与开发这个分类里，讲算法、讲框架、讲架构的视频汗牛充栋，但有一支视频专门死磕一个所有工程师每天都在做、却几乎没人系统学过的事：给变量和函数起名字。CodeAesthetic 的《Naming Things in Code》用不到十分钟的动画，把"命名"从一件被当成琐事的小事，讲成了理解代码质量的入口——为什么坏名字会主动骗人、好名字的五条产生规则、以及"取不出名字"这个信号如何在提示你的设计出了问题。本文按视频的叙事顺序逐点拆解，补上它背后的理论出处与实证研究，也指出它哪些话说得比证据更满。没看过视频，你可以完整吸收它的论证；看过视频，你会知道它每个观点在软件工程文献里的祖籍在哪里。
| 项目 | 内容 |
|---|---|
| 视频标题 | Naming Things in Code（直译：《代码中的命名》） |
| 频道 | CodeAesthetic |
| 发布时间 | 2021年（据频道页面；具体日期未实时核实） |
| 播放量 | 400万以上量级（据频道页面及多方转引，未经实时核实） |
| 时长 | 约10分钟（据频道页面） |
| 形式 | 动画演示 + 代码对比，无真人出镜 |
说明：本篇成稿时未能实时抓取视频页，以上数据为据频道页面与公开引用整理，精确数字请以视频页为准。频道以短小精悍的软件设计动画闻名，多支视频播放量达数百万，这支是其中被引用最多的一支。
视频从软件圈那句流传最广的老梗开场："计算机科学里只有两件难事：缓存失效和命名。"（后面还跟着第三个笑话：差一错误。）这句话常被当作段子转发，但视频认真对待了它：缓存失效再难，多数工程师一周也遇不到几次；而命名是每个工程师每小时都在做的动作。使用频率最高的难题，恰恰是教学中着墨最少的难题——这是全片立论的起点。
第二步论证转移到了"代码到底写给谁看"。视频的答案继承自软件工程的经典立场：代码主要写给人读，只是顺带让机器执行。基于此，它给名字一个极高的定位——名字是你密度最高的文档。理由是：注释写完就死了，代码改动时注释经常被遗忘，慢慢从"文档"腐烂成"谣言"；而名字不同，每一次调用都必须与定义对齐，编译器（或至少是测试与调用方）会强制所有使用处跟它保持一致。所以在视频的框架里：注释是低维护成本的补充说明，名字是唯一被强制保持新鲜的文档。
接下来是一组反面案例，也是全片最有共鸣的段落。data、temp、info、result、manager、utils——这些词的共同问题是：它们描述的信息量为零。一个叫 processData() 的函数，等于在门口挂了块牌子写"这里在干活"。视频进一步指出更危险的一类：撒谎的名字。如果一个函数叫 getUsers()，实际却顺手写了数据库，那么每个读代码的人都会在它面前放下戒心——坏名字不只是浪费读者时间，它会给错误行为盖"检查通过"的章。另一个被点名的反面教材是把类型编码进名字的"匈牙利记号"用法：strName、intCount 这类名字，把本该由类型系统管的账本，强行塞进人脑的记忆里。
论证铺垫完，视频给出正面清单，这也是它被反复收藏的原因——每一条都能在下次写代码时直接用：
overdueCustomers 优于 customerArray；类型信息交给类型系统，语义信息才归名字管。delayMs、heightInMeters、maxRetryCount。单位混用是真实世界的事故源，名字是防线的第一道。isActive、hasLicense 让 if 语句读起来像英语句子；反过来 isNotDisabled 这种双重否定，是每读一次都要心算一次的税。i 无罪；但一个被十几个文件使用的字段，配得上一个自解释的长名。名字长度应该和读者离它的"认知距离"成正比。get、fetch、retrieve 选一个用到底；同一个词不能既指"订单"又指"会话"。更进一步，名字应该跟领域专家嘴里说的一致——用户说"保单"你就别叫"合同对象"。视频的结尾把话题从"技巧"抬到"设计"：如果你给一个模块取名时反复纠结、怎么取都别扭，问题多半不在词汇量，而在这个模块本身职责不清——它可能干了两件事，或者根本不该存在。命名不是给现成的东西贴标签，而是给概念划边界的手段；取名的过程，就是你逼自己想清楚"它到底是什么"的过程。最后的号召很朴素：为名字多花一分钟，未来读代码的人——包括几个月后的你自己——会感谢现在的你。
这支视频没有直接给参考文献，但它的每个论点在软件工程文献里都有明确的祖籍，这是"看过视频还能多懂一层"的部分。
"两件难事"这句话确实有出处。它通常被归于网景公司（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 时读起来不对劲。
flowchart TD
A[命名难题开场<br/>最高频的两难] --> B[代码写给人读<br/>读远多于写]
B --> C[名字是最重要的<br/>活文档]
C --> D[反例<br/>零信息词与撒谎名]
D --> E[写用途不写类型]
D --> F[名字带单位约束]
D --> G[布尔读成问句]
D --> H[作用域定长度]
D --> I[一词一义说行话]
E --> J[取名困难<br/>是设计警报]
F --> J
G --> J
H --> J
I --> J
J --> K[重命名驱动理解<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 等场景全覆盖。