Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

如何改善既有 JS 代码:修复常见的 ESLint 报警(一) #77

Open
cssmagic opened this Issue Oct 25, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@cssmagic
Copy link
Owner

cssmagic commented Oct 25, 2017

前言

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 的做法。

有一个关于 ~ 位运算的奇技淫巧…………

……

……


完整文章在 “CSS魔法” 微信公众号首发,扫码立即阅读:

weixin-post-qr-code


© Creative Commons BY-NC-ND 4.0   |   我要订阅   |   我要打赏

@cssmagic cssmagic added the JavaScript label Oct 26, 2017

@erbing

This comment has been minimized.

Copy link

erbing commented Nov 27, 2017

小组内部各类奇才~ 代码风格完全把我设置的 eslint 忽略,报错任报错。。。

@cssmagic

This comment has been minimized.

Copy link
Owner Author

cssmagic commented Nov 28, 2017

@erbing
要推行代码校验工具,先要达成一致。否则就尴尬了。 😞

@Pines-Cheng

This comment has been minimized.

Copy link

Pines-Cheng commented Dec 15, 2017

可以尝试一下husky @erbing

@weineel

This comment has been minimized.

Copy link

weineel commented Dec 15, 2017

@erbing 可以添加git hook报错不允许提交代码。
可以尝试 husky git hook的nodejs封装。

@riskers

This comment has been minimized.

Copy link

riskers commented Dec 15, 2017

@erbing 要在老项目中推 eslint,lint-staged + husky 是必不可少的,这样每次 commit 的时候只会检查本次有修改的文件。

@zhe-he

This comment has been minimized.

Copy link

zhe-he commented Feb 26, 2018

其实有些位运算可以简化代码。
比如 向下取整 5.222|0 == Math.floor(5.22)
比如 向上取整 -5.222|0 == Math.ceil(-5.22)
比如 ~~'test'

@hax

This comment has been minimized.

Copy link

hax commented Feb 26, 2018

@zhe-he 这种 trick 并没有简化多少,而且你可以试试超过int32范围的数字。

@dan0314

This comment has been minimized.

Copy link

dan0314 commented Jul 10, 2018

@erbing 同命相连 抱头痛哭

@dan0314

This comment has been minimized.

Copy link

dan0314 commented Jul 13, 2018

说起来 我们加了代码不合格禁止提交的检测 然后 我的同组 把src文件放在.eslintignore文件中了……

@cssmagic

This comment has been minimized.

Copy link
Owner Author

cssmagic commented Jul 18, 2018

@dan0314
如果要推行强制的 ESLint,首先要沟通达成一致,其次要修复老代码。

硬上是不行的。硬上的结果就是总会有人想办法绕开。最终破窗效应。

@dan0314

This comment has been minimized.

Copy link

dan0314 commented Jul 23, 2018

@cssmagic 其实是难以沟通 同事固执认为7层嵌套是没问题的 不说了 删库跑路了
PS: 已经把检测文件写进git

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.