10.1 认识代码规范
JavaScript 是动态类型语言，天生就有非常大的灵活性，也产生了风格多样的开发范式。这些优点虽然促使了 JavaScript 繁荣，但是在代码规模激增的背后，“不规范”的问题越来越被凸显出来。
如果你是一名经验丰富的前端开发者，一定接触过这样的项目：变量是 “abc”，“fds” 这种非常随意的命名，或者像 “name1”, “name2” 这种带着数字毫无语义的名字，这样的变量如果不加注释，没有人能读懂它的含义。想象一下一个庞大的项目中全是这一类命名，梳理逻辑时会有多么崩溃。
这类代码就是一种典型的不规范代码，它的特点是没有规则，随意为之，显得混乱难以分类。就像马路上来来往往的车辆，如果不遵守红灯停绿灯行、靠右行驶转向打灯等交通规则，别说无法保证安全，就连正常通行都做不到。
那什么是代码规范？很简单，就是将一些没有标准、灵活的编码和设计用一套规则规范起来，这就是代码规范。
代码规范包含许多规则，变量命名只是其中的一种。还有比如像目录结构规范、标点符号换行规范等。随着项目规模越大，团队越成熟，代码规范的细节也会越来越多。但规范并没有一套强制性的标准，大一点的团队都有各自的规范，只不过一些流行程度较高的规范应用得会更广泛。
那么问题来了：一个小团队，或者几个人的开发小组，还有必要搞代码规范吗？
10.1.1 为什么需要代码规范？
代码规范看起来只是让代码变得好看一点，读起来舒服一点，好像并不会影响执行结果。是的没错，笔者以前也是这样认为的。但是往深层次了想，规范性的代码是不是会间接提高开发效率、保证应用质量？
假设小组内的某个组员像上面一样给变量随意命名，当组内其他人员读到这些代码时，肯定会内心抵触，没有阅读下去的欲望。除此之外，不规范的代码阅读和理解需要花费更多的时间，而且非常容易造成变量冲突，带来未知隐患，对协作者来说无形中增加了成本和风险。
即便某个项目只有一个人开发，只需要自己看懂，不存在协作问题。但是大多时候你不能保证永远不需要他人协助或接手。再换个角度，假设几个月前你开发的某个功能今天要改造升级，当你再看到这些代码时，大概率会忘记当时的思路，还得重新理解这些逻辑，这个时候你就能体会到代码不规范带来的痛苦。
上面的例子只是说了变量不规范。再想下函数不规范、打印不规范、目录不规范，这些不规范结合起来会让项目变得一团糟，结果就是你根本找不到需要的东西在哪里，混乱无比。这样的项目稳定性差，隐藏 Bug 多，维护成本极高，开发效率自然也很低下。
反之，当项目开发过程中所有参与者都遵守一套相同的代码规范时，会使 “一群人的风格” 变成 “一个人的风格”，这样不管项目规模和团队规模有多大，每个人的代码风格都是一样的，不存在互相看不懂的情况，协作成本自然会大幅降低。且同一套规范大家更容易发现问题，做到集思广益，侧面保证了应用质量。
代码规范的目的是提升开发效率和保证应用质量，因此遵守代码规范与团队大小无关。做为一个专业合格的程序员，代码规范是基本要求，也是基本素质。
10.1.2 代码规范包含哪些内容？
前面我们以命名规范为例介绍了规范的意义，这也是大家最能直观感受到的规范。在一个前端项目中，我们可以把代码规范分为以下几个大类：
- 命名规范。
- 格式规范。
- 目录规范。
- 注释规范。
- 类型规范。
这五个大类的规范下还包含不同的规范细则，总之规范越成熟，细节就越多。当然规范要视团队而定，并不是越多越好，有时候太严格的规范反而会影响开发进度。但总体上这几类的开发规范都是要有的，我们设计规范时也要从这几个方面入手。
其中类型规范是指 TypeScript 的规范，如果项目是基于 TypeScript 开发就要格外注意类型的规范。默认情况下，项目中自身会包含大量类型（ES6 类型、DOM 类型），我们自定义的类型要与这些区别开来，且要精准定义。因为类型也很灵活，如果你的的类型全是 any，那么 TypeScript 也就没有意义了。
注释规范比较特殊，它是开发者们最容易忽视的规范 ——— 因为大家根本就不加注释。注释规范首先要求我们必须为特定代码加注释，然后再规定怎么加注释更合理，目的就是帮助协作者快速了解你的代码逻辑。