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