作者在这一话题中讨论编程中一个非常困难和痛苦的点——命名，并对命名给出了以下建议：
命名要有意义，且要准确的表达契约
同一个项目中命名要有一致性，根据项目自己的词汇表命名
及时维护命名
命名要有意义，且要准确的表达契约
这是命名最基本的要求，也是命名让人头大的原因。好的命名能够精准的表达契约，大大的提高代码的可读性，减少其他人的阅读成本。
我的习惯和认知是变量用”形容词+名词“，方法用”动宾短语“。我觉得难点在于：要用最精悍的词汇，准确的表达变量或函数的意义。比如我上周遇到一个需求:用定时任务扫描满足需求的订单，为订单生成NtJob并计费。�这里的难点是对于这个满足条件的sr的描述，因为从查询的角度来说，它要满足很多条件才能被查询出来。而我不可能把这些条件都表达在命名中，这样名称就太长了，也不利于阅读；可是我也不想用Specific 这样的词汇来替代。最后我参考了这类sr在业务上的含义，将这个定时任务命名成了：LtsWorldexDeliveredSrRelatedNtJobWrapper。即便如此，它还是没有表达出“已关联ntJob 的sr不满足条件”和“ntJob自动算费”的含义。
同一个项目中命名要有一致性，根据项目自己的词汇表命名
同一个项目中对特定含义的业务对象是有指定含义的，比如Revenue 是收益，Cost指指出。而“费用”就是中性词汇。这些项目中的特定词汇是对团队有特殊意义的术语，记得在刚入职的时候，听brief 时就常常会因为听不懂特殊名词云里雾里。如果新人Wiki 中能有这样的项目术语表，相信也会对新人融入团队有帮助。
及时维护命名
及时维护命名说起来简单，实操时却往往容易忽视，因为大家在改动代码时往往会更多的关注功能的实现，而命名又是不改也不影响功能的部分。尤其是改动到一个偏底层的方法，会影响这个flow 的功能时，会忘记更改整个Flow的名字。比如下面这个例子：LtsBasfLowerCostTriggerWrapper。 这个flow 最早是为了Basf 压车费命名的，但是现在这个费用叫“待时费”。在需求发生变化时，没有及时的去改名字，导致它偏离了业务含义。
