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