代码命名：你以为是技术活儿？不，这是情商税！

兄弟，有没有过这样的深夜？

你接手了一个“屎山”项目，时间紧，任务重。在某个伸手不见五指的Manager类里，你战战兢兢地打开一个名叫 processData() 的方法。定睛一看，方法签名是这样的：

processData(Object data1, Map<String, String> info, boolean flag)

一瞬间，你是不是感觉血压飙升，仿佛听见了来自上古时代的回响？你内心一万匹草泥马呼啸而过，默默打开git提交记录，只想找到写下这行代码的“大神”，然后抓住他的领子用力摇晃：“你告诉我，data1 是个啥数据？info 又是什么信息？这个 flag 到底是立起来还是放倒下？！”

恭喜你，你刚刚体验了一次“代码考古”的顶级折磨。而这一切的罪魁祸首，就是编程界最低级、也最致命的错误——瞎命名。

很多人觉得，命名嘛，不就是起个名字，代码能跑就行。大错特错！代码是写给人看的，顺便给机器执行。 一个好的命名，是代码的“灵魂”；一个烂的命名，是你亲手埋下的“地雷”。它不仅会炸伤接手的同事，更会在未来的某一天，炸得你自己灰头土脸。

今天，我们就来聊聊，如何靠“命名”这门玄学，终结内卷，告别无效加班，顺便缴纳一下我们欠了多年的“代码情商税”。

第一诫：当“翻译官”，别当“装修工”

核心：体现业务意图，而非实现细节。

想象一个场景：你正在写一个翻译平台的核心逻辑，有一个功能是“把章节状态改成‘翻译中’”。

装修工思维（错误示范）：changeChapterToTranslating()、processChapter()

这两个名字怎么样？看起来好像也没错。但问题在于，它们描述的是“怎么做”（修改状态、处理章节），而不是“做什么”。万一将来业务变了，开始翻译前不止要改状态，还要发通知、建副本呢？你这个 changeChapterToTranslating 就不准了。

翻译官思维（正确示范）：startTranslation()

看到没？格局一下就打开了！我们只关心业务的核心动作——“开始翻译”。至于这个动作背后是改了数据库状态，还是调用了RPC，或是给火箭点了火，那是实现细节，随时可以变。

记住，一个好的方法名，应该能让产品经理都看懂。

第二诫：说“人话”，别拽“黑话”

核心：使用业务词汇，而非技术术语。

接着上面的例子，你需要一个地方存书本信息。

技术宅思维（错误示范）：

• List bookList
• RedisBookStore redisBookStore

bookList… 废话，我不知道这是个List吗？redisBookStore…完了，技术锁死了。明天老板说Redis太贵，要换成Memcached或者公司自研的“盘古缓存”，你怎么办？所有叫redis的地方都得改，改漏一个就等着出生产事故吧。

业务专家思维（正确示范）：

• List books;
• BookCache bookCache;

books，简洁、复数，完美。bookCache，它是什么？是书的“缓存”。至于你用什么技术实现的缓存，那是你的事，别把技术细节暴露给全世界。

好代码就像一个优雅的服务员，他会把菜端上来，但绝不会告诉你后厨有多乱。

第三诫：指名道姓，别搞“无差别攻击”

核心：在上下文中明确角色，而非泛指。

你的翻译平台需要一个“审稿人”来审核稿件。

路人甲思维（错误示范）：approve(chapterId, userId)

这个 userId 是谁的ID？是作者的？是提交者的？还是隔壁老王的？在一个复杂的系统里，这种模糊的命名就是灾难的开始。

侦探思维（正确示范）：approve(chapterId, reviewerId)

reviewerId——审稿人的ID。一清二楚，绝无歧义。代码自己就会说话，根本不需要注释。

高能预警：“命名七宗罪”

请把下面这几个词从你的代码字典里拉黑，看到就想吐的那种：

data, info, flag, process, handle, manage, modify

但凡你的代码里出现这些词，就说明你根本没想清楚你要干嘛。handleData(info, flag) 这种方法，堪称“废话文学”的巅峰之作，应该被钉在代码界的耻辱柱上。

第四诫：守住底线，别逼疯“文化人”

核心：遵循基本法——语法、拼写、和共识。

这是最基础，也最能体现一个程序员专业素养的地方。

1. 语法洁癖：方法是动作，请用动词或动宾短语。类是事物，请用名词。
   • retranslation() (❌) -> retranslate() (✅)
   • completeTranslation() (✅)
2. 杜绝错别字：这简直没法忍！sortFiled？你让用sortField来搜索的人情何以堪？现在IDE都有拼写检查，求求你打开吧！
3. 禁止拼音和“火星文”缩写：这是底线中的底线！
   • save(YongHu yongHu) 这种代码，应该直接开除！
   • xtgl（系统管理？协同过滤？形态概览？）这种缩写，请问你是想加密通话吗？

看过一个笑话，系统里有个核心模块叫 gztz。没人敢动，因为没人知道它到底是“工资条子”、“故障通知”还是“干炸童子”。最后发现是“工作台账”的拼音缩写，而原作者早已离职。这个模块最终被含泪重构，耗费了无数人的青春。

结语：你的命名，就是你的代码名片

兄弟，别再把命名当成一件小事了。

下次当你准备敲下 data1 的时候，请停顿三秒钟，问自己一个问题：

“十年后，当我回看这行代码时，我是会佩服自己当年的远见，还是会想穿越回来给自己一巴掌？”