可以理解成你问过的人对代码质量都没啥要求

我就是有强迫症的人，新项目 eslint 第一部就是配 eslint，看到那种没有 eslint 的代码浑身不自在

我也不太喜欢，但是我很喜欢 prettier

每次写完代码整个文件没有红色就很开心 hhh

我就喜欢 ESLint，但现在待的公司不用。

小马过河

写个 for 遍历 map 都要警告，一行超过 100 行也能警告，确实没什么好感。

我也喜欢，最近刚尝试用到以及的 demo 项目中

看情况，需要协作的情况终究是少数

@afx 定义一个未使用的函数和变量也警告，我特么现在不用不意味着我以后不用啊。。。vue-cli 还自带这东西，警告贴在页面上，真牛皮

eslint + prettier = 超级大炸弹

@afx 这些是规则，可以自己配置。

自己配置，去掉一些扯蛋的规则挺好的

不喜欢的人主要不喜欢那次过于严格的规则限制，又懒得花时间去一个个配置。楼上有人提到 prettier，那是格式化代码用的，跟 lint 工具不是一个东西。我个人觉得还是很有用的，特别是在写 TypeScript 的时候。

主要是是不会配规则吧。
大多数前端连 TS 都不愿意学，就别指望他们主动学 ESLint 了

喜欢 ESLint 的人一般代码质量都不会差；
有自己专属的 ESLint 配置的人一般是强迫症晚期。

（ https://www.npmjs.com/package/eslint-config-sukka 溜了溜了）

eslint + prettier 一个是格式和语法纠错，另一个是代码格式。这两种东西本身可以合并到一起，所以给人的感觉就是太繁杂，我只是想格式化一下代码而已。

@chrisia 即使有脚手架工具，我也觉得这种方式不太优雅，前端的依赖乱七八糟的。

不仅用，而且配置相当严格。ts 直接要求全部声明类型。严格要求自己。
见过不用 lint 的代码，真的就是屎一样，没有约束，都要飞起来了。

linter 是帮助写出有一定基础质量保障的代码的，而不是来让你与他对抗的
写多了代码有团队合作经历的话应该就能理解到，对于 JS 这种灵活度很高的语言来说，自己或者别人不用 linter 写出来的代码，总有一天会不得不亲自品尝里面的酸爽滋味

eslint+prettier 必备，写代码的时候不必在意缩进什么的，一保存就自动格式化代码，不爽吗

eslint 的幸福竟然有人体会不到

屎代码里面游泳感觉好？

说明你的圈子有问题

团队规范，那让用啥就用啥除非你有决策权

个人项目，拿着别人的配置用着不爽就不要怪工具，不爽才是正常的，不自己配等于给自己找不自在

一堆人指着一个 ESlint 各说各的，可能他们用的配置都不是同一套，一个人拿着 A 家的配置用着说 ESlint 垃圾，一个人用着 G 家的配置说好，鸡同鸭讲也能讨论得这么热烈。。
还有只想格式化代码的明明有个单独的 Prettier 不用非要强行加 ESlint 完了还要转进到依赖乱七八糟也是没懂这逻辑。。这用户下沉得有些厉害

挺好的，我们都放 pre-commit 里面，不过不准 commit

一个人开发，格式化就够了，代码规范心里有数

运维这东西跟代码质量没半毛钱关系，只是风格问题。

就好比 golang 自带 format 未引用包自动删除等，但不意味大家写的 golang 代码质量都一样。

不是 eslint 好不好用，而是大部分人写程序真的只是为了糊口，能不多动一点绝对不动，哪怕其实这货一开始要多付出几分钟但会带来后续的持续效率提高

@YUyu101 一个人开发 typescript 也别用了，类型什么心里有数，注释也可以不要，自己写的自己还不清楚

eslint + prettier 可以保证团队代码风格统一，这样提交的时候冲突概率会小很多。至少可以防止因各人格式化工具不同导致的大面积冲突。从这个角度来说它是很好的。

@afx 对了，循环里面用 i++这种也警告，必须要你用 i+=1，反感的不是这软件。反感的是设置垃圾规则的人

因为 js 本身就很乱，每个人都养成了自己的语法习惯，用统一的规则就会很难受，当然如果你是规则的制定者，用的肯定舒服。

它是工具，用来统一代码风格的。
所以在团队里很有用。

看团队需求呗 一个规范而已 没啥好喜不喜欢的

ESLint 的规则和 Prettier 有冲突。
现在 ESLint 也可以对代码进行格式化，没有必要再集成 Prettier 。
必须配置到 pre-commit 里，不然总有人喜欢把一堆乱七八糟的代码放到代码库里。

@molvqingtai 但是总要配置，默认的不喜欢就比较麻烦。
@renmu123 默认规则不好自定义。
@imycc +1
@JerryCha unknown
@PerFectTime 嗯，要是有冲突，很烦人。
@chrisia @torenayto 主要是两个规则有时候会冲突，就很烦人 Eslint 可以调，但是 prettier 自定义比较少，想按照 eslint 的来，就很麻烦。

@hronro #1 这非黑即白的理解是小学生的心智水平
我想你应该很赞同我的描述，因为这句话和你的那句话基本上是同一水平的

如果没有 eslint，我还不知道原来代码可以这么优雅

大家都喜欢指定标准，不喜欢遵守标准，这是人性。

eslint -prettier 插件不是有吗？
有画面感了

eslint 是挺好的工具，团队里用上了，避免出现放飞自我的屎山。
总不能一边批 JS 混乱，又一边自己制造混乱的代码吧？

我待过的 5 家公司，只有一家公司使用了 lint 相关的自动化脚本，也只有那一家使用的是 Git + Gitlab 做版本管理

eslint+airbnb

eslint 本身没啥问题，主要是默认规则太蠢，还给我叫什么 common, 就大家都一样蠢一样审丑吗？

根本不知道啥是美的一个狗东西，大众审美都被拉低了

没用 eslint 的，难道没遇到过改别人代码，可能只改了一个变量名，格式化直接整个文件内容都改了，code review 根本没法做

必须要 eslint 和 prettier 针对不同项目配置不同规则 有时候还需要一点自定义规则

之前不喜欢，直到我知道可以用 eslint 的规则来快速格式化代码后，就很香

有些扯淡的规则干掉就挺舒服的

每个项目必用 eslint，要不然各种个样放飞自我的代码能看到吐血。
我不喜欢它是因为自定义程度太高了，每个人都按自己的「审美」美化，有时候只是想看看别人发过来的代码，一片红，吓人；一格式化一大片修改。
所以我现在换到 go 了，统一的规则，省心，看别人的代码也是熟悉的味道。这样即使用 tab 缩进、大量的 if err != nil 至少占用 3 行 也完全能接受。个人的审美毕竟是主观的。

eslint 是工程项目必备的啊。
我们公司这个是强制的，不 fix 掉，代码根本提交不进去。

eslint 可太好了，自己配置一套易用但是符合基本规范的规则就行。
就是维护离职员工的项目的时候，上百个错误就比较难看

定义一个未使用的函数和变量 typescirpt strict 模式下也过不去,
槽点是自己的不是检测工具的,不用的代码为啥要提交上去有病吧

@ruoxie 用了才不会出现这种问题，你每个人都用各自的格式化配置，一格式化当然整个文件内容都改了，用了统一格式就不会有这问题了

主要是默认的规则太扯淡了，老要去配置
有些祖传项目 npm i 之后，eslint 升了一个小版本，有些原来允许的操作又被禁止了。
老代码又不想改，要么去锁 package 版本，要么去改 eslint 配置，怎么搞怎么蛋疼。

你说要是 golanglint 这种级别的 lint，用起来不怎么用管配置就很舒心。
个人来说，是非常支持 Lint 的，但就是不喜欢 eslint

我觉得 eslint 的问题在于 js 代码格式规范没有一个标准

它们不喜欢是因为懒，不会用

git 钩子强制开启检测，不符合规范的代码提交个毛

@xianxiaobo airbnb 的算业界公认的标准了吧

对自己要求放低就用 eslint-config-standard 凑活也行

不用 eslint, 提交 prettier 一把梭. 别说什么代码质量

eslint 挺好的，至少代码写出来整洁一些

@BarZu

@gouflv

不觉得 eslint 和代码质量有什么强联系
水平低的人在符合 eslint 规则下写出来的代码依旧是垃圾
不过用于团队协作还是可以避免一些低级屎山
那些屎山代码，我想大多是因为逻辑成了屎山，而不是一些代码风格，全等双等之类的区别

你问的都是些什么人

lint 是好东西，然后为啥要求别人的认同

eslint 把不痛不痒的压根不是问题的问题画个红线就没有意思了，让我这种 var 关键字走天下的人情何以堪 此处应该被 /* eslint-disable */

idea 写 java 也是一样的卵毛病，一堆没卵用的警告把很关键甚至致命的警告给淹没了

修改配置？成本很高的，老年人不爱学习了，也很难学动。所以很大程度促进了选择性无视警告

我还以为现在已经几乎没有不用 eslint 的前端了……

不, 那是他们没有追求，多人开发一个项目的时候 eslint+prettier+git 钩子可以一定程度的阻止屎山的堆积速度

写代码一小时，配置 eslint+prettier 一整天

如果团队是 PR+codereview 模型，不用 ESLINT 还能玩？张三写代码不格式化，李四改了一行代码，格式化不格式化？
不格式化怪恶心的，格式化了一提交，几百个变更。

后来 vscode 的哪个插件还做了 [仅格式化文件变更的部分] 这种功能

讨厌 ESLINT 当然是个人自由，但是为什么现在有编程语言开始内置 fmt ？因为这事儿，真的很重要。

Eslint 的规则都可以自己配置，有不喜欢的规则，团队内部直接去掉就是了，这不是工具的问题，是人的问题。

68 楼说得对。
eslint+prettier 日常使用。

团队项目很有必要的，你永远不知道其他开发者有哪些奇葩的写法，甚至各种缩进不规范，一会有空格一会没空格，让人头大。

=.= 规则不是都能配置吗，鸡肋的规则去掉就完事了。既能统一好团队代码风格，还能自动格式化，为什么讨厌 eslint

每个人对团队氛围的要求是不一样的。

很多人都不喜欢被束缚，尤其是我，所以我通常是不会用 eslint 的。

首先要明确一点：JS 是一门极其灵活的语言，一个需求可以用超多种方案来实现，但并不是所有方案都没有隐患，所以对开发者的要求很高，开发者需要有大量的经验以及良好的习惯来规避各种各样的隐患。

于是在团队协作的项目中，你会发现因为每个成员的水平不一样，并不都能驾驭好各种各样的骚操作，以及不同的编码风格可能会导致整体代码的可读性较差；
当代码问题成为阻碍产能的重要问题的时候，就需要工具来辅助：Linter

接下来是另一个共识：工具是用来解决问题的，不是用来制造问题的。

那么如何利用 ESLint 来解决团队已经遇到的问题，同时又不产生更多问题，这个不同的 Leader 可能会有不同的策略。
我的策略是做加法，即为先关闭所有规则，然后把实际代码中的问题搬到 Codereview 会上然后让团队一致同意添加相应的 lint 规则。

我会对规则进行分类：
1. 一定或在绝大多数情况下都会导致缺陷的写法。
2. 虽然不会导致缺陷，但是会较明显地影响代码的可读性。

添加每一种规则的时候，要记录有问题的代码案例，以及为什么添加这一条规则，这样新入职的员工可以参考。

最后就是，这些规则都不是一成不变的，如果随着变化使得某一条规则不再适用，可以随时讨论修改或去掉它。

大多数情况下 prettier 即可，除非是 react deps list 这种

不用 eslint 写出来的好代码，存在吗？是不存在的，在见不得人好的 eslint 使用者看来

eslint 不能阻止屎山堆积，但是能减慢屎山堆积的速度
还有就是从过去的经验来看，很多人都会在本地把自己 eslint 规则改掉

和人合作么?合作的人牛逼么?....合作,合作的人技术不能保证..还有啥好说的,必须 eslint..

但是自己写自己用...我去 TM 的 Eslint...老子爱怎么写怎么写..我就喜欢按空格,我就喜欢定义各种变量不用..管的着么你 eslint 滚一边去.

讨厌的不是 eslint 而是不符合自己风格的规则
对于团队，不管喜不喜欢都得接受团队的规则
对于自己，有 ts，一般不需要 eslint 的约束

我也喜欢 eslint，但是是我自己定规则的 eslint
别人定的都是傻 X 规则……

prettier 提高效率
eslint 我不知道除了爆红拉我高血压还有什么用

我喜欢用 prettier 有时候有些团队 eslint 搞的太严格 有点烦人

很喜欢用，如果不用感觉写代码的时候少点什么。

有专业的人指导你代码什么格式比较好，有什么不好的

@love typescript 是为了自动补全，类型是什么我当然心里有数，但编辑器没数啊。

我只用 prettier，规范格式。

eslint 太严格。公司在意的是你多长时间写出一个页面，而不是你的代码是否优雅。除非公司高层理解高质量项目的重要性，否则还是算了。（我自己的 demo 按照 vue-cli 的配置来，不喜欢的时候就把 vue-element-admin 的配置拷贝一下。）

我们园区团队维护的公共库，连 prettier 都没有，changelog 也没有。我问“能不能写一下 changelog”，对方回答“没时间，你看提交记录吧”。

所以说，要不要用 eslint，看公司，新技术之类的同样如此。忙着赶项目能跑起来就不错了。并且很多小公司的项目根本活不长。

eslint 有些要求确实莫名奇妙，比如 a&&b||c&&d 要求必须在所有&&的周围加括号

eslint 和 prettier 冲突怎么办？按照 eslint 规范改完，一格式化就没了

eslint 就是告诉你一个规则 每个人都要遵守 好处 是 从代码管理上风格统一,方便后续其他人员对接 不友好的 代码限制太多,放荡不羁的程序员 不喜欢条条框框的限制.

lint 是个好东西，如果是在开发新项目时引入，规则统一，我是支持的。

但是如果是在项目都开发了一段时间；或者都开发完成，上线了几个版本，做后续维护的时候引入。还要你让原有代码符合规范，还把这个作为绩效考核的一部分的话，那我选择跑路

很所人不喜欢 eslint 是觉得不自由，但是靠着各种骚操作搞出来都代码质量上可能堪忧

因为很少有人会配置 eslint 就这么简单 他们的项目基本上都是用的一套预设 有的规则确实没什么必要 所以才反感而已