命名艺术段子

接口文档写着返回三个字段，实际返回了五个，还有一个叫 extra 的神秘字段。我在心里把涉及的所有环节都过了一遍。我把这个函数的命名从 save 改成了 persist，回调全改了。感动，然后我学到了新的一课

这个名字在我的理解里是对的，在产品那里不是。我默默记下了这句话。我发现有的地方叫 user，有的叫 customer，其实是同一个。办公室安静得能听见键盘声

新同事问这个类为什么叫 Manager2，我说因为 Manager 被 2018 年的人用过了。我抬起头看了看周围，大家都一样。我把这个类的名字加了 Impl 后缀，其实只有一个实现。感动，然后我学到了新的一课

好的命名让人少看两遍注释，坏的命名让人多写三段注释。我听完沉默了，因为太真实了。我发现有的工具类叫 Utils，有的叫 Helper，还有叫 Util。这大概就是程序员的人生吧

我在命名上纠结了十分钟，最后用了 ctx。我把手上的资料翻出来又读了两遍。我把它改成了更长的全拼，可读性上去了，敲起来手疼。真香定律准时生效

命名规范的存在是为了让人放弃个性化。我叹了口气，然后打开了编辑器。我在评审会上被问到这个名字的语义，我沉默了。第二天这个方案就变成了团队标准做法

好的命名让人少看两遍注释，坏的命名让人多写三段注释。我发现这个名字和系统保留字冲突，只能加后缀。我把这条经验写进了团队 wiki

接口文档写着返回三个字段，实际返回了五个，还有一个叫 extra 的神秘字段。这套流程走下来，我从头到尾又确认了一遍。我把这个测试方法的命名写成了完整一句话，非常长。感动，然后我学到了新的一课

命名艺术的巅峰：把一个字段叫 flag，然后全项目有十七个 flag，含义各不相同。我在心里给这个字段想了个更短的名字，第二天忘了含义。同事说这波操作可以写进新人培训教材

这个类名和它的实现之间有一层说不清的距离。我深呼吸了一下，决定从最可疑的地方查起。我把这个模块的命名缩写展开了一遍，比原来还长。果然现实比段子更精彩