代码编写规范

大家好，我是咕噜老尼，今天我和大家分享一下代码编写的几点规范

• 如何精准命名

命名过于宽泛，命名过于宽泛，无法精准描述。**这是很多代码在命名上存在的严重问题，也是代码难以理解的根源所在：data、info、flag、process、handle、build、maintain、manage、modify 等词语。这种情形不加前缀容易导致界定模糊。

修改完后

命名要能够描述出这段代码在做的事情。一个好的名字应该描述意图，而非细节。

我们之所以要将一段代码封装起来，一个重要的原因就是，很多情况下，我们不想知道那么多的细节。如果把细节平铺开来，那本质上和直接阅读代码细节差别并不大。

用技术术语命名

技术易变，改变之后容易忽略更改命名。用技术术语命名，常用的比如：xxxList、xxxMap、xxxSet 等。

修改完后

使用实际含义命名。因为接口是相对稳定的，而实现是易变的。我们需要面对接口编程，而不是面向实现编程。在实际的代码中，技术名词的出现，往往就代表着它缺少了一个应有的模型。命名要和模型匹配，而不应该使用技术名词。在一个技术类的项目中，这些技术术语其实就是它的业务语言。但对于业务项目，这个说法则不适用。

总结

**用业务语言写代码。**这里业务语言，指的是描述的语言，应该更倾向于业务而不是技术维度。

**编写可维护的代码要使用业务语言。**如何判断是否使用的是业务语言呢？将语言给业务成员看，如果能看懂，则表示使用的业务语言已经符合标准了。

**建立团队词汇表。**使团队业务对于业务有共同理解，不至于出现一个变量含义多种命名方式。

• 如何使用英语命名

对于英语：最低限度的要求是写出来的代码要像是在用英语表达。

使用违反语法的命名方式

修改完后

类名是一个名词，表示一个对象，而方法名则是一个动词，或者是动宾短语，表示一个动作。为函数名，应该是一个动词的形式组合。

不准确的英语词汇

比如同样的“审核”，有使用 review 也有使用 audit 的，那么应该根据业务场景，决定共同使用何种词汇，而不是两者共存。

修改完后

建立起一个业务词汇表，而不是根据自己的主观猜想。

使用集体智慧，而不是个人智慧

总结

**制定代码规范。**比如，类名要用名词，函数名要用动词或动宾短语；在函数方法的命名上，更倾向于使用动宾结构。

**要建立团队的词汇表。**避免每个团队成员依照各自的命名习惯为相同的目标事物使用了不同的命名。

**要经常进行代码评审。**经常性的代码评审可以及时发现这些问题并注意到这些问题。

好了，今天就先讲到这了，我们下次再见！