
我已经给前端项目启用了 240 多条规则, 依然拦不住烂代码, 总是有各种奇奇怪怪的写法, 举个例子: 明明可以好好的写
this.foo = !!value 或者 this.foo = value ? true : false 他这么写我都不会说什么, 就当代码风格问题了, 他们写这样:
value ? this.foo = true : this.foo = false orz, 我今天一天都在调规则加规则以求能把他们这种奇葩写法检测出来了
求助下大家, 有没有现成的成熟项目累积出来的 eslint 规则可以让我抄一份, 不然我这样封封堵堵感觉也蛮难受的
1 daysv 2022 年 8 月 25 日 请直接用 airbnb 的规则 |
2 cyrbuzz 2022 年 8 月 25 日 没绷住= =,笑死。 |
3 wu67 2022 年 8 月 25 日 尼玛我吃着披萨差点喷键盘上了....这什么奇怪代码... |
4 westoy 2022 年 8 月 25 日 那行是生成器生成的吧..... |
5 molvqingtai 2022 年 8 月 25 日 airbnb |
6 gloye 2022 年 8 月 25 日 起码会用个三目 if(value == true){ } |
7 gauzung 2022 年 8 月 25 日 平常都是 if else ,三目能这么用真的没注意到,不过这么写应该容易被打吧 |
8 yeqizhang 2022 年 8 月 26 日 via Android 哈哈哈,js 就是能写出各种奇形怪状的代码 |
9 7gugu 2022 年 8 月 26 日 这第二条确实有点怪 |
10 autoxbc 2022 年 8 月 26 日 感觉就是水平有限,你把所有的路堵死,螃蟹也不能竖着走 |
11 eason1874 2022 年 8 月 26 日 我感觉不是水平问题,是个人偏好,有的人就是不喜欢循规蹈矩,喜欢奇奇怪怪的写法 if (value) alert('hello'); // 他们会写成 value && alert('hello'); |
13 WillBC 2022 年 8 月 26 日 via iPhone 让他们买书看《代码整洁之道》《重构》。进行 Code Review ,不合规的代码不给合并。 |
14 eason1874 2022 年 8 月 26 日 @Qy2FbR #12 这跟楼主的例子一样,在运行上没问题,但属于是用表达式的形式写条件语句,代码短的情况看着还行,代码长的时候可读性就非常差 |
15 515576745 2022 年 8 月 26 日 via Android 后端转前端会有这种情况 比如我 |
16 dabaoziwy 2022 年 8 月 26 日 给你看看我这里的外包小伙伴写的 ts 吧 |
17 dabaoziwy 2022 年 8 月 26 日 const state = reactive<{ id: string | any unitNo: string | any }>({ id: '', unitNo: '' }) |
18 wukongkong 2022 年 8 月 26 日 via Android @dabaoziwy 哼,any 就是好 |
19 Qy2FbR 2022 年 8 月 26 日 via Android @eason1874 不是很同意,这种写法我在不同公司见到过很多次,个人感觉可读性反而更好。 如果你们会写 A = b || foo() 那我觉得 b && foo() 也没啥问题,都是利用 operator short circuit 而已 |
20 hervey0424 2022 年 8 月 26 日 @dabaoziwy anyscript |
21 yaphets666 2022 年 8 月 26 日 @Qy2FbR 问题很大,后面这种写法可读性不好,这不用多说。 |
22 shilianmlxg 2022 年 8 月 26 日 @yaphets666 我一般都是 callback && callback(); // 如果 callback 存在,则立即执行 callback 方法,感觉挺方便的啊。 |
23 ruoxie 2022 年 8 月 26 日 我司整编 jsx 里写好几层三元运算 |
24 yaphets666 2022 年 8 月 26 日 @shilianmlxg 有 promise 我基本不用 callback 了,当然我是写业务的,不是写基建的。 |
27 libook 2022 年 8 月 26 日 linter 只能搞定一些能明确识别且通常是因为疏忽导致的违规,真想提升代码质量,可能只能靠 code review…… 题主发的外包这个代码,第一眼看有点懵,需要捋一遍执行优先级,会很影响看代码的效率;其实如果里面元素都用括号括好,我个人也能接受。 |
29 a33291 2022 年 8 月 26 日 |
30 Leviathann 2022 年 8 月 26 日 @a33291 React jsx 以及没有 optional chain 语法的环境就得这么写 这种属于残废 js 导致的固定 pattern 写法,不是细读,而是识别这个 pattern |
31 taotaodaddy 2022 年 8 月 26 日 |
32 xiao109 2022 年 8 月 26 日 学会接纳自己的屎山和别人的屎山 |
33 taotaodaddy 2022 年 8 月 26 日 @taotaodaddy 发错了... |
34 wuxiaoqing234 2022 年 8 月 26 日 只许天下人负我 不许我负天下人! |
35 murmur 2022 年 8 月 26 日 @eason1874 jsx 习惯这样写,等价于 vue 的 v-if ,这也是我抨击 react 一点,用着奇怪的写法,连最基本的代码对齐都做不到,别人模板一条线极致的优雅,这凸出来一块一块的 |
37 yor1g 2022 年 8 月 26 日 看同事代码 idea 一片黄色 lint 一片红都不管呢 能编译能跑没 bug 啥都不是事 |
38 dsggnbsp 2022 年 8 月 26 日 我觉得大可不必啊 存在即合理哈哈哈哈 ,而且我真的没有觉得过分奇怪。虽然我本人不会这么写 |
39 hzxxx 2022 年 8 月 26 日 有没有可能是他们在玩你呢? vue 源码里就挺多骚写法的,比这个骚多了 |
40 yuancoder 2022 年 8 月 26 日 能看懂就没啥问题 |
41 wenbinwu 2022 年 8 月 26 日 能看懂不就完了嘛 嫌弃的话看到一处改一处就是了 |
42 chaucerling 2022 年 8 月 26 日 加 husky ,不符合规则的代码不能提交 |
43 eason1874 2022 年 8 月 26 日 @Qy2FbR #19 我说了短的看着还行,长了才影响阅读性,你还举短的例子。。。 说它长了影响可读性,不是指用短路写法有影响,而是指用表达式的形式写条件语句有影响 // 像这样只扫一眼就容易看错 var value1 = condition1 || condition2 ? value2 : value3 condition5 && test('txtvalue', value2, value3, value4) (condition1 === 'hello' || condition2 === 'world!') ? test('statement', value1) : test2('statement', value2) // 而常规写法,扫一眼开头的关键字就知道哪里是条件语句,不需额外的反应时间 var value1 = condition1 || condition2 ? value2 : value3 if (condition5) test('txtvalue', value2, value3, value4) if (condition1 === 'hello' || condition2 === 'world!') { test('statement', value1) } else { test2('statement', value2) } |
44 eason1874 2022 年 8 月 26 日 @murmur #35 JSX 这类模板语言用尽量简短的语法,我倒觉得可以,JS 尽量简洁,避免大段的 JS 跟 HTML 混淆在一起。纯 JS 来说,我就觉得这样不好,把一门高级语言写出两种风格,一部分像汇编,一部分又常规语法 |
45 codingBug 2022 年 8 月 26 日 |