写了三年代码才明白的事：读别人代码的时间远多于自己写。所以好的命名不是洁癖，是给三个月后的自己，也是给下一个接手的人留的便条。以前我总觉得变量名只要自己当下看得懂就行，赶进度时甚至会用一两个字母把逻辑糊过去。等到需求变更、同事接手，或者几个月后重新打开旧项目，真正耗时的往往不是写新代码，而是猜测当时为什么这样写。清晰的命名还会逼着人把职责边界想明白：这个函数到底返回状态、执行动作，还是顺便修改了别处的数据。它不能替代注释和测试，却能让搜索、重构和代码评审都更顺畅。给未来的自己留一条准确的线索，通常比今天少敲几下键盘更划算。命名也不必一开始就完美，重要的是随着业务理解加深及时修正，并在评审时解释这个词代表的真实概念。

内容来自用户上传，真假由发布者声明。