推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
This topic created in 2064 days ago, the information mentioned may be changed or developed.
 |
hronroMar 17, 2021
1
可以理解成你问过的人对代码质量都没啥要求
|
 |
2
我就是有强迫症的人，新项目 eslint 第一部就是配 eslint，看到那种没有 eslint 的代码浑身不自在
|
1 |
3
我也不太喜欢，但是我很喜欢 prettier
|
 |
4
每次写完代码整个文件没有红色就很开心 hhh
|
 |
QingStoneMar 17, 2021 via iPhone
5
我就喜欢 ESLint，但现在待的公司不用。
|
 |
gouflvMar 17, 2021 via iPhone
6
小马过河
|
 |
afxMar 17, 2021 via iPhone
7
写个 for 遍历 map 都要警告，一行超过 100 行也能警告，确实没什么好感。
|
 |
fxjsonMar 17, 2021 via Android
8
我也喜欢，最近刚尝试用到以及的 demo 项目中
|
 |
reijiMar 17, 2021
9
看情况，需要协作的情况终究是少数
|
 |
11
可能你没有碰过一个变量必须定义为 any，husky 告诉你这样不行，git 回滚还碰到 permission denied 的时候。
|
 |
PerFectTimeMar 17, 2021
12
eslint + prettier = 超级大炸弹
|
 |
liyang5945Mar 17, 2021
14
自己配置，去掉一些扯蛋的规则挺好的
|
 |
BiwoodMar 18, 2021 via iPhone
15
不喜欢的人主要不喜欢那次过于严格的规则限制，又懒得花时间去一个个配置。楼上有人提到 prettier，那是格式化代码用的，跟 lint 工具不是一个东西。我个人觉得还是很有用的，特别是在写 TypeScript 的时候。
|
 |
16
主要是是不会配规则吧。
大多数前端连 TS 都不愿意学，就别指望他们主动学 ESLint 了 |
 |
17
喜欢 ESLint 的人一般代码质量都不会差；
有自己专属的 ESLint 配置的人一般是强迫症晚期。 （ https://www.npmjs.com/package/eslint-config-sukka 溜了溜了） |
 |
chrisiaMar 18, 2021
18
eslint + prettier 一个是格式和语法纠错，另一个是代码格式化。这两种东西本身可以合并到一起，所以给人的感觉就是太繁杂，我只是想格式化一下代码而已。
|
 |
duan602728596Mar 18, 2021 via iPhone
20
不仅用，而且配置相当严格。ts 直接要求全部声明类型。严格要求自己。
见过不用 lint 的代码，真的就是屎一样，没有约束，都要飞起来了。 |
 |
sekiMar 18, 2021
21
linter 是帮助写出有一定基础质量保障的代码的，而不是来让你与他对抗的
写多了代码有团队合作经历的话应该就能理解到，对于 JS 这种灵活度很高的语言来说，自己或者别人不用 linter 写出来的代码，总有一天会不得不亲自品尝里面的酸爽滋味 |
 |
torenaytoMar 18, 2021 via iPhone
22
eslint+prettier 必备，写代码的时候不必在意缩进什么的，一保存就自动格式化代码，不爽吗🤣
|
 |
huijieweiMar 18, 2021 via iPhone
23
eslint 的幸福竟然有人体会不到
屎代码里面游泳感觉好？ |
 |
PerryMar 18, 2021 via iPhone
24
说明你的圈子有问题 🐶
|
 |
25
团队规范，那让用啥就用啥除非你有决策权
个人项目，拿着别人的配置用着不爽就不要怪工具，不爽才是正常的，不自己配等于给自己找不自在 一堆人指着一个 ESlint 各说各的，可能他们用的配置都不是同一套，一个人拿着 A 家的配置用着说 ESlint 垃圾，一个人用着 G 家的配置说好，鸡同鸭讲也能讨论得这么热烈。。 还有只想格式化代码的明明有个单独的 Prettier 不用非要强行加 ESlint 完了还要转进到依赖乱七八糟也是没懂这逻辑。。这用户下沉得有些厉害 |
 |
ayase252Mar 18, 2021 via iPhone
26
挺好的，我们都放 pre-commit 里面，不过不准 commit
|
 |
27
一个人开发，格式化就够了，代码规范心里有数
|
 |
wangxiaoaerMar 18, 2021 via iPhone
28
运维这东西跟代码质量没半毛钱关系，只是风格问题。
就好比 golang 自带 format 未引用包自动删除等，但不意味大家写的 golang 代码质量都一样。 |
 |
loveMar 18, 2021
29
不是 eslint 好不好用，而是大部分人写程序真的只是为了糊口，能不多动一点绝对不动，哪怕其实这货一开始要多付出几分钟但会带来后续的持续效率提高
|
 |
31
eslint + prettier 可以保证团队代码风格统一，这样提交的时候冲突概率会小很多。至少可以防止因各人格式化工具不同导致的大面积冲突。从这个角度来说它是很好的。
|
 |
chenmobuysMar 18, 2021
33
因为 js 本身就很乱，每个人都养成了自己的语法习惯，用统一的规则就会很难受，当然如果你是规则的制定者，用的肯定舒服。
|
 |
ShookMar 18, 2021
34
它是工具，用来统一代码风格的。
所以在团队里很有用。 |
 |
rodrickMar 18, 2021
35
看团队需求呗 一个规范而已 没啥好喜不喜欢的
|
 |
vicalloyMar 18, 2021
36
ESLint 的规则和 Prettier 有冲突。
现在 ESLint 也可以对代码进行格式化，没有必要再集成 Prettier 。 必须配置到 pre-commit 里，不然总有人喜欢把一堆乱七八糟的代码放到代码库里。 |
 |
yimityMar 18, 2021
37
@molvqingtai 但是总要配置，默认的不喜欢就比较麻烦。
@renmu123 默认规则不好自定义。 @imycc +1 @JerryCha unknown @PerFectTime 嗯，要是有冲突，很烦人。 @chrisia @torenayto 主要是两个规则有时候会冲突，就很烦人 Eslint 可以调，但是 prettier 自定义比较少，想按照 eslint 的来，就很麻烦。 |
 |
BarZuMar 18, 2021
39
如果没有 eslint，我还不知道原来代码可以这么优雅
|
 |
hongjiapeiMar 18, 2021
40
大家都喜欢指定标准，不喜欢遵守标准，这是人性。
|
 |
ccraohngMar 18, 2021 via iPhone
41
eslint -prettier 插件不是有吗？
有画面感了 |
 |
AV1Mar 18, 2021
42
eslint 是挺好的工具，团队里用上了，避免出现放飞自我的屎山。
总不能一边批 JS 混乱，又一边自己制造混乱的代码吧？ |
 |
lightjiaoMar 18, 2021
43
我待过的 5 家公司，只有一家公司使用了 lint 相关的自动化脚本，也只有那一家使用的是 Git + Gitlab 做版本管理
|
 |
wangyzjMar 18, 2021
44
eslint+airbnb
|
 |
EPr2hh6LADQWqRVHMar 18, 2021
45
eslint 本身没啥问题，主要是默认规则太蠢，还给我叫什么 common, 就大家都一样蠢一样审丑吗？
根本不知道啥是美的一个狗东西，大众审美都被拉低了 |
 |
ruoxieMar 18, 2021
46
没用 eslint 的，难道没遇到过改别人代码，可能只改了一个变量名，格式化直接整个文件内容都改了，code review 根本没法做
|
 |
grewerMar 18, 2021
47
必须要 eslint 和 prettier 针对不同项目配置不同规则 有时候还需要一点自定义规则
|
 |
javapythongoMar 18, 2021
48
之前不喜欢，直到我知道可以用 eslint 的规则来快速格式化代码后，就很香
|
 |
Lee2019Mar 18, 2021
49
有些扯淡的规则干掉就挺舒服的
|
 |
KengMar 18, 2021
50
每个项目必用 eslint，要不然各种个样放飞自我的代码能看到吐血。
我不喜欢它是因为自定义程度太高了，每个人都按自己的「审美」美化，有时候只是想看看别人发过来的代码，一片红，吓人；一格式化一大片修改。 所以我现在换到 go 了，统一的规则，省心，看别人的代码也是熟悉的味道。这样即使用 tab 缩进、大量的 if err != nil 至少占用 3 行 也完全能接受。个人的审美毕竟是主观的。 |
 |
yazooxMar 18, 2021
51
eslint 是工程项目必备的啊。
我们公司这个是强制的，不 fix 掉，代码根本提交不进去。 |
 |
ERRASYNCTYPEMar 18, 2021
52
eslint 可太好了，自己配置一套易用但是符合基本规范的规则就行。
就是维护离职员工的项目的时候，上百个错误就比较难看 |
 |
myCupOfTeaMar 18, 2021
53
定义一个未使用的函数和变量 typescirpt strict 模式下也过不去,
槽点是自己的不是检测工具的,不用的代码为啥要提交上去有病吧 |
 |
mxT52CRuqR6o5Mar 18, 2021
54
@ruoxie 用了才不会出现这种问题，你每个人都用各自的格式化配置，一格式化当然整个文件内容都改了，用了统一格式就不会有这问题了
|
 |
pkoukkMar 18, 2021
55
主要是默认的规则太扯淡了，老要去配置
有些祖传项目 npm i 之后，eslint 升了一个小版本，有些原来允许的操作又被禁止了。 老代码又不想改，要么去锁 package 版本，要么去改 eslint 配置，怎么搞怎么蛋疼。 你说要是 golanglint 这种级别的 lint，用起来不怎么用管配置就很舒心。 个人来说，是非常支持 Lint 的，但就是不喜欢 eslint |
 |
xianxiaoboMar 18, 2021
56
我觉得 eslint 的问题在于 js 代码格式规范没有一个标准
|
 |
66betaMar 18, 2021
57
它们不喜欢是因为懒，不会用
git 钩子强制开启检测，不符合规范的代码提交个毛 |
|
58
|
 |
zhuweiyouMar 18, 2021
59
不用 eslint, 提交 prettier 一把梭. 别说什么代码质量
|
 |
keepeyeMar 18, 2021
60
eslint 挺好的，至少代码写出来整洁一些
|
 |
yyzclMar 18, 2021 via Android
63
不觉得 eslint 和代码质量有什么强联系
水平低的人在符合 eslint 规则下写出来的代码依旧是垃圾 不过用于团队协作还是可以避免一些低级屎山 那些屎山代码，我想大多是因为逻辑成了屎山，而不是一些代码风格，全等双等之类的区别 |
 |
miniwade514Mar 18, 2021
64
你问的都是些什么人
|
 |
loopljMar 18, 2021
65
lint 是好东西，然后为啥要求别人的认同
|
 |
xiangyuecnMar 18, 2021
66
eslint 把不痛不痒的压根不是问题的问题画个红线就没有意思了，让我这种 var 关键字走天下的人情何以堪😂 此处应该被 /* eslint-disable */
idea 写 java 也是一样的卵毛病，一堆没卵用的警告把很关键甚至致命的警告给淹没了 修改配置？成本很高的，老年人不爱学习了，也很难学动。所以很大程度促进了选择性无视警告 |
 |
KyrieJoshuaMar 18, 2021
67
我还以为现在已经几乎没有不用 eslint 的前端了……
|
 |
justsosososoMar 18, 2021
68
不, 那是他们没有追求，多人开发一个项目的时候 eslint+prettier+git 钩子可以一定程度的阻止屎山的堆积速度
|
 |
TomatoYuyukoMar 18, 2021
69
写代码一小时，配置 eslint+prettier 一整天
|
 |
VegetableMar 18, 2021
70
如果团队是 PR+codereview 模型，不用 ESLINT 还能玩？张三写代码不格式化，李四改了一行代码，格式化不格式化？
不格式化怪恶心的，格式化了一提交，几百个变更。 后来 vscode 的哪个插件还做了 [仅格式化文件变更的部分] 这种功能 讨厌 ESLINT 当然是个人自由，但是为什么现在有编程语言开始内置 fmt ？因为这事儿，真的很重要。 Eslint 的规则都可以自己配置，有不喜欢的规则，团队内部直接去掉就是了，这不是工具的问题，是人的问题。 |
 |
SZP1206Mar 18, 2021
71
68 楼说得对。
eslint+prettier 日常使用。 |
 |
jimliangMar 18, 2021
72
团队项目很有必要的，你永远不知道其他开发者有哪些奇葩的写法，甚至各种缩进不规范，一会有空格一会没空格，让人头大。
|
 |
JaaaaackZhengMar 18, 2021
73
=.= 规则不是都能配置吗，鸡肋的规则去掉就完事了。既能统一好团队代码风格，还能自动格式化，为什么讨厌 eslint
|
 |
74
每个人对团队氛围的要求是不一样的。
很多人都不喜欢被束缚，尤其是我，所以我通常是不会用 eslint 的。 首先要明确一点：JS 是一门极其灵活的语言，一个需求可以用超多种方案来实现，但并不是所有方案都没有隐患，所以对开发者的要求很高，开发者需要有大量的经验以及良好的习惯来规避各种各样的隐患。 于是在团队协作的项目中，你会发现因为每个成员的水平不一样，并不都能驾驭好各种各样的骚操作，以及不同的编码风格可能会导致整体代码的可读性较差； 当代码问题成为阻碍产能的重要问题的时候，就需要工具来辅助：Linter 接下来是另一个共识：工具是用来解决问题的，不是用来制造问题的。 那么如何利用 ESLint 来解决团队已经遇到的问题，同时又不产生更多问题，这个不同的 Leader 可能会有不同的策略。 我的策略是做加法，即为先关闭所有规则，然后把实际代码中的问题搬到 Codereview 会上然后让团队一致同意添加相应的 lint 规则。 我会对规则进行分类： 1. 一定或在绝大多数情况下都会导致缺陷的写法。 2. 虽然不会导致缺陷，但是会较明显地影响代码的可读性。 添加每一种规则的时候，要记录有问题的代码案例，以及为什么添加这一条规则，这样新入职的员工可以参考。 最后就是，这些规则都不是一成不变的，如果随着变化使得某一条规则不再适用，可以随时讨论修改或去掉它。 |
 |
kingwlMar 18, 2021
75
大多数情况下 prettier 即可，除非是 react deps list 这种
|
 |
charlie21Mar 18, 2021
76
不用 eslint 写出来的好代码，存在吗？是不存在的，在见不得人好的 eslint 使用者看来
|
 |
zhlssgMar 18, 2021
77
eslint 不能阻止屎山堆积，但是能减慢屎山堆积的速度
还有就是从过去的经验来看，很多人都会在本地把自己 eslint 规则改掉 |
 |
MarszmMar 18, 2021
78
和人合作么?合作的人牛逼么?....合作,合作的人技术不能保证..还有啥好说的,必须 eslint..
但是自己写自己用...我去 TM 的 Eslint...老子爱怎么写怎么写..我就喜欢按空格,我就喜欢定义各种变量不用..管的着么你 eslint 滚一边去. |
 |
joshua7vMar 18, 2021
79
讨厌的不是 eslint 而是不符合自己风格的规则
对于团队，不管喜不喜欢都得接受团队的规则 对于自己，有 ts，一般不需要 eslint 的约束 |
 |
wobuhuicodeMar 18, 2021
80
我也喜欢 eslint，但是是我自己定规则的 eslint
别人定的都是傻 X 规则…… |
 |
81
prettier 提高效率
eslint 我不知道除了爆红拉我高血压还有什么用 |
 |
luvxyMar 18, 2021
82
我喜欢用 prettier 有时候有些团队 eslint 搞的太严格 有点烦人
|
 |
lizhesystemMar 18, 2021
83
很喜欢用，如果不用感觉写代码的时候少点什么。
|
 |
danieladuMar 18, 2021
84
有专业的人指导你代码什么格式比较好，有什么不好的
|
 |
KMpAn8Obw1QhPoEPMar 18, 2021 via Android
85
@libook 每次看您的回复都有所收获 再次感谢
|
 |
tony1890Mar 18, 2021
87
我只用 prettier，规范格式。
eslint 太严格。公司在意的是你多长时间写出一个页面，而不是你的代码是否优雅。除非公司高层理解高质量项目的重要性，否则还是算了。（我自己的 demo 按照 vue-cli 的配置来，不喜欢的时候就把 vue-element-admin 的配置拷贝一下。） 我们园区团队维护的公共库，连 prettier 都没有，changelog 也没有。我问“能不能写一下 changelog”，对方回答“没时间，你看提交记录吧”。 所以说，要不要用 eslint，看公司，新技术之类的同样如此。忙着赶项目能跑起来就不错了。并且很多小公司的项目根本活不长。 |
 |
stockmasterMar 19, 2021
88
eslint 有些要求确实莫名奇妙，比如 a&&b||c&&d 要求必须在所有&&的周围加括号
|
 |
dumbassMar 19, 2021 via iPhone
89
eslint 和 prettier 冲突怎么办？按照 eslint 规范改完，一格式化就没了🤨
|
 |
jzmwsMar 19, 2021
90
eslint 就是告诉你一个规则 每个人都要遵守 好处 是 从代码管理上风格统一,方便后续其他人员对接 不友好的 代码限制太多,放荡不羁的程序员 不喜欢条条框框的限制.
|
 |
07lyMar 19, 2021
91
lint 是个好东西，如果是在开发新项目时引入，规则统一，我是支持的。
但是如果是在项目都开发了一段时间；或者都开发完成，上线了几个版本，做后续维护的时候引入。还要你让原有代码符合规范，还把这个作为绩效考核的一部分的话，那我选择跑路 |
 |
xingguangMar 19, 2021
92
很所人不喜欢 eslint 是觉得不自由，但是靠着各种骚操作搞出来都代码质量上可能堪忧
|
 |
cereschenMay 7, 2021
93
因为很少有人会配置 eslint 就这么简单 他们的项目基本上都是用的一套预设 有的规则确实没什么必要 所以才反感而已
|
Select Language