写了很多年 js ,都是用三等号。即使类型不匹配也要强制使用 Number String 等方式转换一下再判断。
现在发现双等号直接可以帮你转类型后再比较。
甚至可以这么用: if (a == 0) { ... }, 这里当 a 是 0 / "" / false 时候都成立。
看到很多项目都把双等号给禁了( eslint eqeqeq ),没仔细研究,但有些情况下还是不错的。
1
aisles1 18 小时 58 分钟前 无脑===
|
2
june4 18 小时 55 分钟前
val == null 应该是 js 基本常识技能吧?那判断为 null 你是怎么做的? val === null || val === undefined?
|
3
gorvey 18 小时 53 分钟前 |
4
qiaobeier 18 小时 53 分钟前
十多年前我用这个当面试题来着😂
|
7
l864494871 18 小时 48 分钟前
@ethusdt 他的意思是当判断是否为 null 时只需要==即可。
|
8
ixixi 18 小时 48 分钟前
不知道啊 ,我用 ts
|
9
wu00 18 小时 37 分钟前
十几年前好像都是==
|
10
maplezzz 18 小时 36 分钟前
隐式转换设计的太复杂了,不同的类型,各种各样可能的 case ,用的时候很容易出现意料之外的问题
|
11
jydeng 18 小时 32 分钟前
太麻烦了,容易出问题
|
13
MinorN 18 小时 29 分钟前
坚决 === ,我同事曾经用 == 找了 1h 的 bug ,然后叫我帮忙看看哪里出了问题
|
14
cpstar 18 小时 29 分钟前
if(!!val)
|
15
masterclock 18 小时 18 分钟前 完全不适用 ==,只用 ===
不直接使用 if(a),全部包装成基于业务语义的 isNull isEmpty isValid isGood... |
16
g17 18 小时 9 分钟前 无脑 === ,手动转类型
|
17
aloxaf 18 小时 6 分钟前
> 甚至可以这么用: if (a == 0) { ... }, 这里当 a 是 0 / "" / false 时候都成立。
我觉得代码中就不应该出现 a 有可能是 0 / "" / false 的情况…… |
18
temporary 18 小时 0 分钟前
如果需要展示的情况,0 需要展示,而 "" NaN null undefined 大概率要展示成 -
|
19
ethusdt OP @june4 #12 哦,我明白了,就是判断某个值是 null ,而非 0/空字符串/false 之类的具体值。但是业务场景下,这些都是一样效果,用户没有填一个值那就给默认 false/0/空字符串,除非有特殊需求默认成其他值。
我想到的就这点了。能再举几个例子场景么。 |
20
craftsmanship 17 小时 54 分钟前 via Android
@masterclock 是个提升代码可读性和健壮性的好习惯
|
21
crocoBaby 17 小时 52 分钟前
卧槽,我一直偷懒用的==,确实遇到 0 和 false 和 null 的问题
|
22
craftsmanship 17 小时 51 分钟前 via Android 总有人说 JS 简单 结果在双等和三等上面都分不清楚适用场景,,,也分不清 falsy value 和 nullish value
真特么菜。 |
23
craftsmanship 17 小时 46 分钟前 via Android
JS 是个由于初期设计太过垃圾而导致引入过多不必要的复杂性的语言 有大量细节需要记忆 由于不规范导致的灵活性让人可以玩花活 写出来的代码难读难维护 反直觉的设计让不熟悉这门语言的人踩很多坑 很多使用者根本意识不到自己在干什么 看看上面的回复就知道了
从改善这些缺点来讲 TS 是大救星 |
24
shintendo 17 小时 44 分钟前
|
25
craftsmanship 17 小时 43 分钟前 via Android
@maplezzz 不是设计得太复杂了 而是当初压根没有设计 完全 PL 外行拍脑袋搞出来的垃圾
|
26
craftsmanship 17 小时 40 分钟前 via Android
@shintendo 我原来就是遵守这个规范 但现在感觉#15 的做法更好 完全避免 JS 的那些隐式语义 包成 util 不费劲而且一目了然 让所有人都能读懂意图
|
27
tonytonychopper 17 小时 37 分钟前
@crocoBaby 这还能偷懒吗,出 bug 了就老实了
|
28
tonytonychopper 17 小时 37 分钟前
@craftsmanship #23 是的,但是这些设计问题变成了面试题来拷打从业者……
|
29
meteor957 17 小时 34 分钟前
@tonytonychopper ===和== 甚至面试都不应该问,完全没有使用 == 的理由,默认===就行。
|
30
craftsmanship 17 小时 30 分钟前 via Android
@tonytonychopper 怎么说呢 为了八股而八股的话 完全没必要 属于做题大国的坏习惯 但八股里考察的点 其实是有意义的 只是以八股的形式出现很恶心
比如隐式转换就能看出使用者对 JS 的熟悉程度 也是非常常见的坑点 想全记住规则并不现实 因为确实太复杂 但这个都不了解的话 那完全不合格 然而所有这些在 AI 时代已经不重要了… |
31
craftsmanship 17 小时 27 分钟前 via Android
@meteor957 有 #24 已经提过了 再具体点说就是 唯一使用双等的场景 就是用来判断 nullish value
面试时值得问的点太多了 隐式转换确实不合适 因为这应该是 JS 基本功 默认是了解的 |
32
GuguDan 17 小时 26 分钟前
用的,因为有时候接口就是会返回 ‘0’
|
33
craftsmanship 17 小时 22 分钟前 via Android
@GuguDan 坏习惯 这种应该 Number(val) === 0 而非偷懒使用双等的隐式转换
想玩花活?没问题 +val === 0 少打几个字母 让代码变得晦涩难读 有意义吗?完全没意义 但很多人这样写 显得自己很 6 这就是 JS |
34
hafuhafu 17 小时 21 分钟前
以前前端工程化没流行开的时候,只用`==`的人大把,甚至反而很多人都不知道`===`。特别是一些后端顺便写前端的人。
多亏了前端工程化和各种创建项目的脚手架以及开源项目里面用了 ESLint ,倒逼大家去学习一些规范。 说个我感觉很搞笑的事,以前看到有不少人搜 ESlint 报红怎么解决,最后的方案是卸载掉... |
35
gdw1986 17 小时 18 分钟前 via Android
这种现在交给 AI 应该没什么难度吧
|
36
Shaar 17 小时 18 分钟前
我刚入行做 cocos-js 开发的时候,根本不知道===这个东西,一直用== 直到出现了一个隐形 bug ,查了非常久才知道有==和===的问题,十年了,我都无法忘怀这个东西
|
37
crocoBaby 17 小时 16 分钟前
@tonytonychopper 借机跟测试小妹说话
|
38
lueluev 17 小时 14 分钟前
我去,开倒车
|
39
wangtian2020 17 小时 5 分钟前
我只用 == 很少用严格===。
项目我一个前端没人管我。 == 能没问题的地方 === 一定没问题。=== 会出现问题的地方 == 可能反而没问题。 通常情况下只有会 string number 之类的在进行比较,其他一切比较情况都是写法有问题 |
40
wangtian2020 17 小时 3 分钟前
@aloxaf 动态类型转换为 false 的我直接 if(a){} 了
|
41
woodcutter 17 小时 1 分钟前
小程序页面穿参会把 number 转成 string ,一般我想省事就用==,懒得再转了。
|
42
akakidz 16 小时 52 分钟前
双等号就是邪修,TC39 委员会的人,也不能把双等号在项目里用明白 太复杂了!下一个维护项目的人,难道要在脑子里跑一遍所有场景下状态机 预判前人写的双等号可能要处理的业务逻辑?
|
43
silverwzw 16 小时 43 分钟前
用 a === b || (a !== a && b !== b)
|
44
realpg PRO 我是邪修 我很常用 == 必要时候才 ===
大概是弱类型语言用的太多了 对==和===一般不会写出 bug |
45
zbinlin 16 小时 22 分钟前
只有一种情况会用:判断是 等于或不等于 null 和 undefined 时。
|
46
meteor957 15 小时 47 分钟前 via Android
@craftsmanship 不太懂,难道你说的这种场景用 === 做不到嘛,为啥是唯一场景,==只是更简洁吧。
|
47
ASHYWHISPER 15 小时 38 分钟前
我在想,反正基本上都是无脑===为什么 ES 规范,不直接将==表示===的作用呢,当然我是刚学前端的 JS 初学者
|
48
craftsmanship 15 小时 31 分钟前 via Android
@akakidz 是的 所以 JS 心智负担很大
|
49
kdwnil 15 小时 30 分钟前 via Android
多数时候都不应该用==,但特殊情境下,手搓超短代码的时候可以靠这种隐式转换省一点空间,就用了
|
50
craftsmanship 15 小时 29 分钟前 via Android
@meteor957 可能我表述得不太清楚 不是只有双等能做得到 而是说双等只在这种情况下值得使用
|
51
craftsmanship 15 小时 28 分钟前 via Android
@ASHYWHISPER 当然是为了兼容性 怎么可能在语言的新版本里更改原来语法的语义呢 这就是所谓的历史包袱重
|
52
meteor957 15 小时 1 分钟前
@craftsmanship 既然如此,=== 依然可以 cover 所有场景且没有太多成本。我刚刚说面试都不应该问的原因是不管是实际开发还是面试都应该默认遵守使用===的规则,当你使用==时本身就引入了不必要的心智负担。
|
53
craftsmanship 14 小时 56 分钟前 via Android
@meteor957 是的 完全赞同
|
54
qwerty12345 14 小时 52 分钟前
老项目里全是[==],还好没有出过什么大问题,现在重构了,基本都是[===]
|
55
v21984 14 小时 37 分钟前
除 == null 或者 == undefined 这两种情况外,全使用 ===
|
56
CarryOnHxy 14 小时 34 分钟前
eslint eqeqeq 规则有个 smart 模式
|
57
TimPeake 13 小时 57 分钟前
|
58
rm0gang0rf 13 小时 57 分钟前
全是==也挺好
|
59
TimPeake 13 小时 55 分钟前
|
60
chairuosen 13 小时 49 分钟前
|
61
IamUNICODE 13 小时 41 分钟前
我是直接设置 eslint 警告的,不接受==
|
62
freezebreze 13 小时 19 分钟前
现在回想起来以前学 js 。在没有 ai 的年代,简直是在历屎中遨游
|
63
Strive123456 13 小时 6 分钟前
肯定是用三等
|
64
94 12 小时 56 分钟前
早期很长一段时间用的 == 因为学编程的时候就是 = 和 ==。
后面业务写的多起来之后才慢慢改成 ===。一些地方该用 _.isNill 之类的就用,而不是自己去写空值判断逻辑。 隐式转换有些时候是好用,但是有一些时候会埋坑。 |
65
LandCruiser 11 小时 50 分钟前
处理==null 这种问题的唯一正确方式是,if ( valid ){}else{} 而不是 if ( unvalid ){}
|
66
icyalala 10 小时 14 分钟前
|
67
SanjinGG 10 小时 10 分钟前
@june4 #12 但 js 中的 null 更多应该指的是未赋值的对象,或者空对象,一般也就 val 是 object 时才会出现 null ,他为什么存在空串,0 的情况? if(val)完全够用。js 只是没有强约束,但应该也没憨憨就一个变量,一直赋值不同类型值一路使用吧?
|
69
AV1 9 小时 58 分钟前
|
70
june4 9 小时 32 分钟前
@SanjinGG 啊,你哪怕是用 ts,就没有见过这种类型 `number | null | undefined` ? 或 `string | null | undefiend`
|
71
Aliceeeeee 9 小时 29 分钟前 via iPhone
禁用==。同时也绝不使用 null, 一律 undefined
|
72
Aliceeeeee 9 小时 24 分钟前 via iPhone
@craftsmanship "掌握"了语言设计上的两个 billion dollar mistake 然后沾沾自喜么
|
73
craftsmanship 9 小时 17 分钟前 via Android
@Aliceeeeee 你需要增强阅读理解能力
|
74
AoEiuV020JP 7 小时 32 分钟前
确实有时候感觉双等号是不是方便点, 尤其奇葩项目中 userId 是 string|number 混用的,
但 AI 写的代码总是用三等号, 搞得我都不好意思要求双等号了, 不过我是纯 ts , |
75
nicenight 7 小时 23 分钟前
只要你不用单等号,我都能接受。你要是像我同事一样用单等号做判断,那我就要放狗了
|
77
qingshui33 4 小时 15 分钟前
@gorvey 昨天刚遇到了,0.4 / 10000 ,出来结果是 0.39999... 😪
|
78
craftsmanship 56 分钟前 via Android
@Aliceeeeee 同时 null 和 undefined 的语义是不一样的 这种 billion dollar mistake 你要不要了解下再写 JS ?
|