前端规范与思考(三)—— JavaScript规范 javascript

本文属于原创文章，转载请注明--来自桃源小盼的博客
前言虽然这个系列是前端规范，但是我的理解稍稍不同。

代码格式：具体到换行，符号，空格等每一个细节

代码规范：一定要这么做
最佳实践：最好要这么做

代码格式自然是让prettier来做。
这个系列是代码规范和一部分最容易实施的最佳实践的组合。
1.优先使用es6+新语法

解构赋值
class类

箭头函数
- 函数参数默认值
- 可选链 ?.

只列出了部分特性，es6+的语法，表达性更好，如果还没学会或者不习惯。
那就强迫自己去学习和习惯，然后你就喜欢上了它。
2.函数必须添加多行注释例外情况：生命周期函数

/** * 发起批量处理 */ function launchBatch() { batching.value = https://www.it610.com/article/true }

其实最好的注释，就是依赖方法命名和方法参数命名来表达含义。
但现实是每个团队的情况都不同，国人英文素质普遍谈不上好，所以不能仅仅依靠方法命名。
所以我们在第一版的规范中规定，如果开发中个人认为这个函数名不容易理解，那么需要增加注释。如果函数参数值多样，也需要注释说明。
然而真实的情况是，每个人觉得自己的函数命名易懂，所以几乎没有注释。所以这一次才要求所有函数必须注释。
3.函数长度一般控制在20行以内为什么是20行？综合多种因素吧。个人的经验、易维护程度、模块化。
其实20行就是个风向标，如果真的就是21行，就说这段代码不好吗？
自然不是，这条规范是在提醒每一个开发者，超过20行的时候，重新审视这段代码。
当然了，有的代码就算10行以内，也不是好代码。
4.函数参数超过二个可以改为参数对象

const item = await getItemFromCollection(54391, 'shop')// better const item = await getItemFromCollection({ id: 54391, collectionName: 'shop', })async function getItemFromCollection({ id, collectionName }) { // do something }

参数对象的方式，从调用者的角度，更容易理解参数的含义，相当于在调用这里，就帮助我们做了参数命名。否则我们就要去函数定义的地方，查看相关的说明。
5.函数参数不要定义为boolean类型 6.尽量不使用switch case 7.用卫语句替换嵌套的条件表达式

// bad function getPayAmount() { let result if (isDead) { result = deadAmount() } else { if (isSeparated) { result = separatedAmount() } else { if (isRetired) { result = retiredAmount() } else { result = normalPayAmount() } } } return result }// good function getPayAmount() { if (isDead) { return deadAmount() } if (isSeparated) { return separatedAmount() } if (isRetired) { return retiredAmount() } return normalPayAmount() }

8.多字符串拼接使用模板字符串

// bad const str = 'a' + 'b' + test// good const str = `ab${test}`

9.优先使用迭代器遍历 10.循环嵌套三次的时候，复杂度为O(n^3)，注意性能问题如果想更好地处理这类问题，还是需要组内伙伴都具备算法知识。
只不过现实情况通常不同，考虑到很多人缺乏算法知识，所以有了这一条。
还是那句话，没有最好的规范，只有适合与更好的规范。
11.业务相关的数字，需要定义常量

// bad if (type === 1) { // doSomething } else if (type === 2 ) { // doSomething }// good const MANAGER = 1 const GENERAL = 2if (type === MANAGER) { // doSomething } else if (type === GENERAL ) { // doSomething }

12.this转换命名self 13.工具函数优先使用lodash 推荐使用lodash-es库，为了webpack的tree shaking优化体积。
14.特殊业务逻辑要增加单行注释 【前端规范与思考(三)—— JavaScript规范】特殊的业务，通常能记住的情况因人而异，有可能你一直记着这个特殊的业务逻辑，有可能你在一周后就忘记了。为了团队，也为了未来的自己，写好记录。
15.尽早删除TODO注释 16.过期代码及时删除真想找回，可以查看git历史记录。
17.尽早删除调试console.log语句如果在代码里写了很多的调试语句，也许是调试代码的方式不够好，试试debugger方式。
18.特殊情况