你应该像给第一个孩子取名那样谨慎地给变量命名。——罗伯特·C·马丁
—读完这句，什么在心中回响？
命名不是小事
罗伯特·C·马丁这句话看似夸张，其实是在提醒程序员：变量名从来不是可有可无的装饰，而是代码表达意图的第一语言。就像给第一个孩子取名时，人们会反复斟酌含义、发音与未来影响，变量命名同样需要承担沟通、辨识与传承的责任。 进一步说，代码往往写给人看，其次才是给机器执行。编译器并不在乎变量叫 x 还是 totalOrderAmount，但后来接手的同事、几个月后的自己，却高度依赖这些名字来理解系统。因此，一个随意的名字，常常会把原本简单的逻辑包裹成不必要的迷雾。
好名字传达真实意图
紧接着，这句话的核心并不只是“要认真”，而是“名字必须准确表达意图”。在 Martin 的《Clean Code》(2008) 中，他反复强调，好的名称应当说明变量保存了什么、为什么存在、如何被使用。相比 data、temp、obj 这类模糊词，userAge、invoiceTotal、isArchived 明显更能降低理解成本。 于是，命名就成了一种设计行为，而不仅是书写行为。当一个变量名足够清晰时，注释的需求会减少，阅读者也不必频繁跳转上下文猜测含义。换句话说，清楚的命名本身就是代码可读性最直接、也最廉价的投资。
草率命名会积累认知债务
然而，如果名字取得含混、过时或带有误导性，问题并不会立刻爆发，却会像技术债一样不断累积。一个名为 count 的变量，可能存的是分页总数、当前数量，甚至重试次数；而 status 这样的名称，如果没有限定范围，也往往让人无从判断其业务语义。 随后，团队成员在维护时就不得不把精力花在猜测上，而不是解决真正的问题。许多线上缺陷并非源于复杂算法，而是源于理解偏差。也正因如此，谨慎命名实际上是在减少误读，避免让未来的修改建立在错误假设之上。
命名体现抽象与边界
再往深处看，变量名不仅影响可读性，还暴露了程序员对业务抽象的理解程度。一个好名字会自然体现对象边界与领域概念，比如在电商系统中使用 cartItems、pendingPayment、shippingAddress，就比 list1、flag2、info 更能贴近真实业务。 这也解释了为什么命名常常很难：困难不在于找词，而在于想清楚“这东西究竟是什么”。从这个角度说，命名过程本身就是梳理模型的过程。若一个变量迟迟难以命名，往往不是词汇量不够，而是设计尚未真正清晰。
慎重命名是一种长期责任
最后，马丁用“第一个孩子”作比喻，还强调了命名的情感分量与长期影响。孩子的名字会伴随其成长，变量名也会在重构、协作、扩展中持续出现，进入函数、接口、文档乃至团队共同语言。名字一旦传播开来，修改成本就会迅速上升。 因此，认真命名并不是吹毛求疵，而是对未来维护者负责。优秀程序员和普通程序员的差别，往往不只在于能否写出可运行的代码，更在于能否写出容易被理解、被信任、被修改的代码。而这一切，常常就从一个变量名开始。
一分钟思考
这句话给你带来了什么感受？
相关名言
已选2条代码能运行还不够。——罗伯特·C·马丁
罗伯特·C·马丁
罗伯特·C·马丁这句话首先提醒我们：软件开发的目标从来不只是“跑起来”。一个程序能够通过编译、完成基本功能，当然值得肯定；然而进一步看，这往往只是交付的最低门槛，而不是质量的终点。正因如此，“能运行还不够”听上去像批评，实则是在把注意力从结果表象拉回到工程本质。 换句话说，真正优秀的代码还必须具备可理解、可维护和可扩展的特性。马丁在《Clean Code》（2008）中反复强调，代码首先是写给人读的，其次才是让机器执行的。也正是在这一层...
阅读完整解读 →如果你想快点前进，如果你想迅速完成，如果你希望你的代码易于编写，那就让它易于阅读。——Robert C. Martin
罗伯特·C·马丁
Robert C. Martin 这句话看似矛盾：想更快前进，竟然要先让代码“慢下来”，多花心思去写得清楚易读。然而进一步看，这恰恰指出了软件开发中最常见的误区——许多人把“尽快写完”误认为“真正高效”。实际上，仓促堆砌的代码常常会在后续调试、修改和协作中成倍地消耗时间。
阅读完整解读 →更多作者内容
来自罗伯特·C·马丁的更多内容 →代码能运行还不够。——罗伯特·C·马丁
罗伯特·C·马丁这句话首先提醒我们：软件开发的目标从来不只是“跑起来”。一个程序能够通过编译、完成基本功能，当然值得肯定；然而进一步看，这往往只是交付的最低门槛，而不是质量的终点。正因如此，“能运行还不够”听上去像批评，实则是在把注意力从结果表象拉回到工程本质。 换句话说，真正优秀的代码还必须具备可理解、可维护和可扩展的特性。马丁在《Clean Code》（2008）中反复强调，代码首先是写给人读的，其次才是让机器执行的。也正是在这一层...
阅读完整解读 →如果你想快点前进，如果你想迅速完成，如果你希望你的代码易于编写，那就让它易于阅读。——Robert C. Martin
Robert C. Martin 这句话看似矛盾：想更快前进，竟然要先让代码“慢下来”，多花心思去写得清楚易读。然而进一步看，这恰恰指出了软件开发中最常见的误区——许多人把“尽快写完”误认为“真正高效”。实际上，仓促堆砌的代码常常会在后续调试、修改和协作中成倍地消耗时间。
阅读完整解读 →