Go从入门到进阶，大厂案例全流程实践(无密，完结)

Go从入门到进阶，大厂案例全流程实践(无密，完结)

下载看水印

上文中使用find、get、query这些动词来命名，但是如果一个相同概念的操作用到多种动词，那么就不太好了，应该让这些词汇功能单一，比如数据库原子(不做处理)查询只用get，而逻辑查询和复杂查询则只用find或者query，因为get操作看起来太过于纯粹，而实际上我们对于复杂数据的索引实则不是直接获取，而是查找筛选，当然，如果你愿意使用其他方式表达这种关系或者不在意这么细节，那就没有多大关系，综合当前环境和条件来考虑编码规范。

包括上文的类名中的manager和processor这些词汇也是一样，在于综合可虑，不能一棍子打死，说这样不行或者这样可以，他对于一些刚开始熟悉你代码的开发者可能会带来理解上的成本，比如他会想Manager结尾的类是做什么的，此时你如果提供一份说明文档，那么他会更方便阅读你的代码，而不是像以前所有的逻辑全是Service，这样Servcie的职责概念太过于广泛，容易在命名上模糊职责而不能准确体现，那么这样看来，定义一些新的规约是一把双刃剑，合理使用才是王道。

不要使用双关语

比如add这个词汇，Number.add()是将数字相加的含义，但是如果有些开发者想保持风格统一，就会在一些类中将元素添加到容器的方法命名为add，那么此时实际上不是相加的意思，应该用append更加合适。

迎合当前技术领域

对于大部分的后端程序员，我相信对于JobQueue(工作任务的队列)的意义一眼就能秒懂，这个名称放在前端貌似也没问题，但是如果我改为EventQueue(这里是笔者自己觉得在前端使用event词汇概念更多，job我在前端几乎没有使用过，因为前端本身所有操作都是基于浏览器事件循环，我更乐意理解为每一个操作都是一个事件而不是一个任务)或许对于前端程序员会更加易懂。

以及在C/C++中使用包含pointer单词命名我不会觉得有问题，但是在Java中如果出现了一个包含pointer词汇的命名，我或许真的会有些疑惑。

迎合业务领域命名

不多说，财务系统会有自身一套成体系的术语，OA系统也会有一套自身体系的术语，对于专业领域开发，迎合术语命名能让业务和开发交流更加通畅。