3种常见的代码规范类型

从事web开发已有7个年头，经历过几个团队和很多项目，也面试过一些开发者。 发现不一样公司对代码规范这一块的要求相差很大，有的公司甚至没有规范。 究其原因，无非是项目紧张，没有时间整理。 长此以往，随着项目不断变大，维护变得困难，各类问题暴露出来：代码可读性差、修改容易出bug、逻辑混乱。。。 因此在技术上稍有追求的团队都意识到规范的重要性。

代码规范的意义

先思考一个问题：什么是好的代码？

你可能给出不少意见，好比：

• 少用全局变量。
• 高内聚，低耦合。
• 遵循单一原则。
• 拥有注释说明。
• 。。。

站在开发者我的层面来思考问题，全部这些“独善其身”的道理都正确。 但若是更进一步，站在团队的角度，考虑到维护代码的开发者会不断地变动；加入时间维度，考虑到代码会不断地被修改。

什么样的代码才是好代码？

曾经看到有位做者说“风格一致”的代码就是好代码，即团队全部人写出来的代码就像是一我的所写的。这个观点我很是赞同。

有的读者可能会反驳，代码写得同样就是好吗？要是团队成员水平很低，写得代码都很烂呢？

首先，若是团队成员水平都很低，那么写出来的代码不会是“风格一致”，而会是“风格迥异”。 回想本身最初编程的时候是否是常常在网上搜索代码，而后直接赋值粘贴再改改，发现能用就以为OK了？ 这种质量的代码不只成员之间写的代码具备风格差别，就连同一个开发者写的代码也会有所不一样。

“风格一致”背后的意义是什么？

如今的开发工做被不断分化，前端、后端、交互设计师、产品经理。。。 这符合英国经济学家亚当斯密在《国富论》中提出的“分工带来效率”，可是带来的最大问题就是沟通（这里的“沟通”指信息的交流方式）成本上升，例如前端和设计师沟通可能经过psd文件，和后端沟通会经过API。

因此会有REST API设计风格，会有GraphQL。本质上都是在造成共识，下降沟通成本。“风格一致”的代码规范的做用就和它们同样，旨在下降开发者因写做风格差别而带来的维护成本。由于代码虽然是运行在机器上，但终究仍是给人看的。

为了造成好的代码规范，都有哪些方式？

看不见的规范

看不见的规范指的就是“靠人规范”。 这是最简单粗暴的方式，依赖开发者我的经验来指点入职新人进行代码编写，或者依靠偶尔进行的代码分享和评审。 全部的代码规范都在开发者脑壳里，基本靠语言传递。 这种靠“口口相传”的开发规范，对于学习者来讲由于无文档可查，全凭我的记忆。 因此根据我的经验不一样、记忆力不一样，不一样的开发者会有不一样的规范，难以保证代码风格一致。

看得见的规范

不少团队都会用编写各类规范文档。 百度、谷歌上随手一搜“开发规范”，能够找到大量的文章。 这种方式解决了规范执行依赖“老员工靠经验，新员工靠记忆”的问题，由于造成了文字，一方面能够修订，一方面能够查看。 可是文档终究只是文档，即便文档写得再好，但代码仍是可能写得一团糟。 执行效果的保障成了新的问题~

无处不在的规范

在这种状况下代码检验工具应运而生，开发者能够把编码规范写成配置文件，再配合工具对代码进行检验。 同时在开发环境中使用插件来实时提示开发者遵照校验规则。 即便开发者提交了不符合规范的代码，也能够在部署以前用多种方式阻止代码部署，好比利用git的钩子程序或者在持续集成中进行检验。 这种方式很具备工程思惟，能合理利用工具解决问题，这样的代码已经基本具备“风格一致”的特色了。但校验工具的做用也是有限的，没法理解代码语义。

理想的代码规范

既然这些都不完美，到底有没有更好的解决方案？

没有~也有~

确实没有找到一劳永逸的工具或方法，可是值得庆幸的是咱们能够把他们结合起来：使用静态校验工具来规范代码的基本书写规范，而后对于校验工具没法完成的规范写成文档，最后经过代码合并时的代码审查进行保障。

例如我为如今前端项目的规范就包括多种形式：

• 对于脚本语言TypeScript和预处理语言Sass，直接省略了规范文档，采用的是使用对应的校验工具tslint和sasslint，编辑器集成的插件能够及时提醒开发者遵循规范，对于有疑问的错误信息也很容易在网上进行查找。
• 对于比较灵活的部分，如变量命名、文件建立以及代码内容则采用文档描述加上代码评审的方式，评审方式为互评，先由其它开发者查阅代码进行评论，而后再转给管理员进行审核。

固然这种方式在初期的磨合成本是会略高一些，好比校验规则没有文档说明，评审耗费时间等。可是随着开发不断进行，这种成本会不断下降到趋近于0，由于代码写的越多对规范越熟悉，评审改进次数越多也能促进团队在编码上达成共识。同时在代码达成一致以后这些同事也能够为新加入团队的同事提供指导和帮助。从经济学的角度来讲，就是边际成本递减和收益递增。

最后

懂得避免的问题赛过懂得解决问题，好的规范能避免写出糟糕的代码，为之后节省大量重构、修复bug的时间。