blog
blog copied to clipboard
如何改善既有 JS 代码:修复常见的 ESLint 报警(一)
前言
ESLint 是目前最流行、最强大的 JS 代码校验工具。它不仅可以帮助我们统一代码风格,更重要的是,它还可以帮助我们发现代码中可能存在的错误。
当我们根据自己的需要设置好 ESLint 的报警规则,并集成到编辑器(或构建工具)之后,ESLint 就开始为我们服务了——在开发时(或构建时)对我们的代码给出校验结果、提示错误。
在 ESLint 提供的这些规则中,有些是可以一键自动修复的,而有些则需要我们手工介入,针对性地修复有问题的 JS 代码。
本系列文章将详细讲解那些需要手工介入修复的 ESLint 规则,帮助你把既有代码顺利迁移到 ESLint 的保护之中。
eqeqeq
这条规则要求我们把 “模糊判断” 改为 “精确判断”。它是最常用的 ESLint 校验规则之一。
大家都知道,== 具有隐式的类型转换能力(比如 2 == '2' 判断成立),因此当我们需要 “模糊地” 对比两个值时,往往倾向于使用 == 和 !=。
举个很常见的例子,我们不确定后端接口给出的某个值到底是数字还是字符串,往往会这样写:
if (response.errorCode == 0) {
// do something...
}
这种写法看起来很好用,为什么还要禁止它呢?问题在于 == 和 != 所采用的那一套类型转换规则远比我们想像的复杂。比如说,我们很难一眼看出 null == 0 的判断结果如何。这种隐式的复杂度很容易让我们踩坑,因此很多团队的代码规范都要求放弃使用 == 和 !=。
好,既然如此,我们接下来看看如何去掉代码中的这些 == 吧!
其实方法并不复杂,如果我们需要做 “跨类型” 比较,就先显式地把类型转换一致吧:
if (parseInt(response.errorCode, 10) === 0) {
// do something...
}
或者这样:
if (String(response.errorCode) === '0') {
// do something...
}
no-bitwise
这条规则会禁用所有位运算符。
“位运算” 在日常开发中并不常用,如果我们在代码中写出位运算符,多半是手滑敲错了,或者是为了耍帅。比如,用它写一个 IIFE(立即调用的函数表达式):
~function () {
// do something...
}()
这种写法确实很帅,因为它令新手不明觉厉,尊你为大神。然而我们的追求不应该是 “不明觉厉”,而应该是 “一目了然”。因此,建议你用其它模式来写 IIFE。
比如,如果你采用传统的写行末分号的代码风格,可以采用传统的 IIFE 书写方式:
(function () {
// do something...
})();
如果你的风格是不写行末分号,则可以这样写:
void function () {
// do something...
}()
no-implicit-coercion
这条规则可以禁止隐式的类型转换,包括用
~位运算判断-1的做法。
有一个关于 ~ 位运算的奇技淫巧——它可以判断一个数字是否为 -1。它在配合字符串或数组的 .indexOf() 方法时,非常炫酷:
// 判断字符串的包含关系
if (~str.indexOf(substr)) {
// do something...
}
然而这种写法并不易读,而且会触发 no-implicit-coercion 这条规则报警(显然也会触发上面那条 no-bitwise 规则)。
建议采用更加直观的写法:
if (str.indexOf(substr) !== -1) {
// do something...
}
或者采用 ES6+ 为字符串和数组提供的新方法 .includes():
// 判断字符串的包含关系
if (str.includes(substr)) {
// do something...
}
或者采用第三方类库提供的 API:
// 判断数组是否包含某个成员
// jQuery / Zepto
if ($.inArray(member, array)) {
// do something...
}
// Underscore / Lodash
if (_.includes(array, member)) {
// do something...
}
// 判断字符串的包含关系
// Gearbox
if (gearbox.str.includes(str, substr)) {
// do something...
}
如你所见,这些建议的写法都比那个神秘的波浪号直观多了。
(待续……)
本文在 “CSS魔法” 微信公众号首发,扫码立即订阅:
小组内部各类奇才~ 代码风格完全把我设置的 eslint 忽略,报错任报错。。。
@erbing 要推行代码校验工具,先要达成一致。否则就尴尬了。 😞
可以尝试一下husky @erbing
@erbing 可以添加git hook报错不允许提交代码。 可以尝试 husky git hook的nodejs封装。
@erbing 要在老项目中推 eslint,lint-staged + husky 是必不可少的,这样每次 commit 的时候只会检查本次有修改的文件。
其实有些位运算可以简化代码。 比如 向下取整 5.222|0 == Math.floor(5.22) 比如 向上取整 -5.222|0 == Math.ceil(-5.22) 比如 ~~'test'
@zhe-he 这种 trick 并没有简化多少,而且你可以试试超过int32范围的数字。
@erbing 同命相连 抱头痛哭
说起来 我们加了代码不合格禁止提交的检测 然后 我的同组 把src文件放在.eslintignore文件中了……
@dan0314 如果要推行强制的 ESLint,首先要沟通达成一致,其次要修复老代码。
硬上是不行的。硬上的结果就是总会有人想办法绕开。最终破窗效应。
@cssmagic 其实是难以沟通 同事固执认为7层嵌套是没问题的 不说了 删库跑路了 PS: 已经把检测文件写进git
