## 关于 ESLint 规则的一些个人理解在 JavaScript 开发中代码质量一直是个绕不开的话题。这些年接触过不少项目有些代码写得清晰规范维护起来很顺畅有些则像是不同人用不同方言写出来的文章读起来费劲改起来更是小心翼翼。ESLint 规则就是在这个背景下逐渐成为开发标配的。规则到底是什么简单来说ESLint 规则就是一套代码检查的标准。它不是编译器不会阻止代码运行而是在你写代码的过程中或者提交代码之前告诉你哪些写法可能有问题哪些地方不符合团队的约定。这有点像写作时的语法检查工具。你写一篇文章工具会提示你这里用了被动语态那里句子太长或者某个词有更合适的替代词。规则本身不判断文章好坏只是指出可能存在的问题改不改、怎么改还是作者自己决定。每个规则都有自己明确的检查范围。有些规则很严格比如要求所有字符串必须用单引号有些则比较宽松只是建议性的比如提醒某个函数可能过于复杂。规则的严格程度可以配置这也是它灵活的地方。它能解决的实际问题最直接的作用是保持代码风格一致。团队里每个人都有自己的编码习惯有人喜欢在行末加分号有人不喜欢有人习惯用两个空格缩进有人用四个。这些差异本身不影响程序运行但混在一起会让代码看起来杂乱无章。规则可以统一这些细节让整个项目的代码看起来像是同一个人写的。更重要的是规则能发现一些潜在的错误。比如变量声明了却没使用这可能是忘记删除的冗余代码比如在循环中创建函数可能导致闭包问题比如使用了已废弃的 API。这些检查能在代码运行前就发现问题省去了不少调试时间。还有一点容易被忽视规则可以作为团队的知识传承。新成员加入项目通过规则配置就能了解这个项目的编码规范不需要老成员一遍遍口头交代。规则文档本身就成了最好的入门指南。实际使用中的体会刚开始接触规则时很容易陷入两个极端要么一条规则都不加觉得太麻烦要么把所有能找到的规则都加上结果处处报错写代码寸步难行。比较实际的做法是从小处着手。先选几个最基础的规则比如缩进、引号、分号这些格式相关的。等团队适应了再逐步添加更复杂的规则比如变量作用域、函数复杂度之类的。这个过程需要时间不能指望一蹴而就。配置规则时建议分成几个层次。最底层是基础规则所有项目通用中间层是框架相关规则比如 React 项目、Node.js 项目各有侧重最上层是项目特有规则针对具体业务需求定制。这样配置起来清晰也方便复用。现在很多编辑器都能集成 ESLint写代码时就能看到提示这比写完再检查要高效得多。提交代码前的检查也很有必要可以在 git hook 里加入检查步骤确保提交的代码都符合规范。一些实践中的经验规则不是越多越好。有些规则检查的东西过于琐碎反而会影响开发效率。选择规则时要考虑实际价值那些能真正提高代码质量、避免错误的规则才值得启用。规则的严格程度需要平衡。太松了起不到作用太严了大家会想方设法绕过检查。比较好的做法是对于可能导致错误的规则设为错误级别必须修改对于风格类的规则设为警告级别可以暂时忽略。规则也需要定期维护。JavaScript 生态变化很快新的语法特性不断出现旧的规则可能不再适用。每隔一段时间回顾一下规则配置该调整的调整该废弃的废弃。特别想说的一点是规则终究是工具不能替代人的判断。有些情况下违反规则反而是更好的选择。这时候就需要禁用规则或者添加例外。关键是要有充分的理由并且在代码注释中说明为什么这么做。和其他工具的对比市面上类似的工具不少比如 JSHint、JSLint还有最近比较流行的 Prettier。每个工具都有自己的特点。JSLint 出现得最早但规则不可配置必须按照作者认为正确的方式来写代码。这在早期有一定价值但缺乏灵活性。JSHint 在 JSLint 基础上改进允许配置规则一度很流行。但它对 ES6 及更新语法的支持不够及时逐渐被 ESLint 超越。ESLint 最大的优势是架构设计。它采用插件机制核心只提供解析和运行环境具体规则由插件提供。这种设计让它可以快速支持新的语法特性社区生态也特别活跃。Prettier 是另一种思路。它不检查代码而是直接格式化代码。你可以把它看作是自动排版工具。ESLint 和 Prettier 并不冲突反而可以配合使用Prettier 负责代码格式ESLint 负责代码质量。很多项目都是两者一起用各司其职。选择工具时关键看团队的需求。如果只是要统一的代码风格Prettier 可能更简单直接如果需要深度的代码质量检查ESLint 更合适。实际上现在很多项目都是两者结合取长补短。最后的一些想法用了这么多年 ESLint最大的感受是好的工具应该融入工作流程而不是成为负担。规则配置得合适它就像是个贴心的助手在你可能犯错时提醒一下配置得不合适它就成了烦人的监工处处挑刺。规则的本质是沟通。它让团队成员用同一种“语言”写代码让代码审查有明确的标准让项目维护更可预期。从这个角度看配置规则的过程其实就是团队就编码规范达成共识的过程。技术总是在变化今天的最佳实践可能明天就过时了。规则也需要与时俱进但核心目标不会变写出更清晰、更健壮、更好维护的代码。这大概就是为什么 ESLint 能成为现代 JavaScript 开发不可或缺的一部分吧。