求推荐下成熟项目的 vue2 可用 eslint 规则, 我要被外包兄弟的代码质量搞疯了

[retrocode]

我已经给前端项目启用了 240 多条规则, 依然拦不住烂代码, 总是有各种奇奇怪怪的写法, 举个例子: 明明可以好好的写

this.foo = !!value 或者 this.foo = value ? true : false

他这么写我都不会说什么, 就当代码风格问题了, 他们写这样:

value ? this.foo = true : this.foo = false

orz, 我今天一天都在调规则加规则以求能把他们这种奇葩写法检测出来了

求助下大家, 有没有现成的成熟项目累积出来的 eslint 规则可以让我抄一份, 不然我这样封封堵堵感觉也蛮难受的

[daysv]

请直接用 airbnb 的规则

[cyrbuzz]

没绷住= =，笑死🤣。

[wu67]

尼玛我吃着披萨差点喷键盘上了....这什么奇怪代码...

[westoy]

那行是生成器生成的吧.....

[molvqingtai]

airbnb

[gloye]

起码会用个三目
if(value == true){

}

[gauzung]

平常都是 if else ，三目能这么用真的没注意到，不过这么写应该容易被打吧

[yeqizhang]

哈哈哈，js 就是能写出各种奇形怪状的代码

[7gugu]

这第二条确实有点怪

[autoxbc]

感觉就是水平有限，你把所有的路堵死，螃蟹也不能竖着走

[eason1874]

我感觉不是水平问题，是个人偏好，有的人就是不喜欢循规蹈矩，喜欢奇奇怪怪的写法

if (value) alert('hello'); // 他们会写成

value && alert('hello');

[Qy2FbR]

@eason1874 后面这种写法有啥问题吗

[WillBC]

让他们买书看《代码整洁之道》《重构》。进行 Code Review ，不合规的代码不给合并。

[eason1874]

@Qy2FbR #12 这跟楼主的例子一样，在运行上没问题，但属于是用表达式的形式写条件语句，代码短的情况看着还行，代码长的时候可读性就非常差

[515576745]

后端转前端会有这种情况 比如我 🤣

[dabaoziwy]

给你看看我这里的外包小伙伴写的 ts 吧

[dabaoziwy]

const state = reactive<{
id: string | any
unitNo: string | any
}>({
id: '',
unitNo: ''
})

[wukongkong]

@dabaoziwy 哼，any 就是好

[Qy2FbR]

@eason1874 不是很同意，这种写法我在不同公司见到过很多次，个人感觉可读性反而更好。
如果你们会写
A = b || foo()
那我觉得
b && foo() 也没啥问题，都是利用 operator short circuit 而已

[hervey0424]

@dabaoziwy anyscript

[yaphets666]

@Qy2FbR 问题很大，后面这种写法可读性不好，这不用多说。

[shilianmlxg]

@yaphets666 我一般都是 callback && callback(); // 如果 callback 存在，则立即执行 callback 方法，感觉挺方便的啊。

[ruoxie]

我司整编 jsx 里写好几层三元运算

[yaphets666]

@shilianmlxg 有 promise 我基本不用 callback 了，当然我是写业务的，不是写基建的。

[w3q29]

@dabaoziwy 写完 any 之后因为 eslint 有提示，再用注释把 eslint 提示给屏蔽掉🤣

[stoluoyu]

@dabaoziwy #17 那个这个 string 是为了……

[libook]

linter 只能搞定一些能明确识别且通常是因为疏忽导致的违规，真想提升代码质量，可能只能靠 code review……

题主发的外包这个代码，第一眼看有点懵，需要捋一遍执行优先级，会很影响看代码的效率；其实如果里面元素都用括号括好，我个人也能接受。

[dabaoziwy]

@stoluoyu 这就是我的吐槽点，乱用联合类型。。。

[a33291]

@eason1874 我也习惯后边这么写 🤣,还有其他人吗,举个手统计下


题外话,我突然有点理解为啥写 java 的会说 C#甜得齁了,因为他们限制了大家就只有一种写法.

[Leviathann]

@a33291 React jsx 以及没有 optional chain 语法的环境就得这么写
这种属于残废 js 导致的固定 pattern 写法，不是细读，而是识别这个 pattern

[taotaodaddy]

https://en.wikipedia.org/wiki/Short-circuit_evaluation

[xiao109]

学会接纳自己的屎山和别人的屎山

[taotaodaddy]

@taotaodaddy 发错了...

[wuxiaoqing234]

只许天下人负我 不许我负天下人！

[murmur]

@eason1874 jsx 习惯这样写，等价于 vue 的 v-if ，这也是我抨击 react 一点，用着奇怪的写法，连最基本的代码对齐都做不到，别人模板一条线极致的优雅，这凸出来一块一块的

[gauzung]

@a33291 #29 🙋‍♂

[yor1g]

看同事代码 idea 一片黄色 lint 一片红都不管呢 能编译能跑没 bug 啥都不是事

[dsggnbsp]

我觉得大可不必啊 存在即合理哈哈哈哈 ，而且我真的没有觉得过分奇怪。虽然我本人不会这么写

[hzxxx]

有没有可能是他们在玩你呢？
vue 源码里就挺多骚写法的，比这个骚多了

[yuancoder]

能看懂就没啥问题

[wenbinwu]

能看懂不就完了嘛
嫌弃的话看到一处改一处就是了

[chaucerling]

加 husky ，不符合规则的代码不能提交

[eason1874]

@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)
}

[eason1874]

@murmur #35 JSX 这类模板语言用尽量简短的语法，我倒觉得可以，JS 尽量简洁，避免大段的 JS 跟 HTML 混淆在一起。纯 JS 来说，我就觉得这样不好，把一门高级语言写出两种风格，一部分像汇编，一部分又常规语法

[codingBug]

antfu 大佬的，fork 一份或者直接用这套

https://github.com/antfu/eslint-config