ESLint vs Prettier

静态分析的问题
所以有一个叫“赖斯”的人，他说，“我们真的无法了解任何程序的任何有趣之处”赖斯定理。好吧，当。

这是一个非常大的问题，因为我们真的很想知道这段代码有用吗？

赖斯定理并没有完全阻止静态分析，但它确实告诉我们，静态分析的每一次尝试都会在某种程度上存在缺陷。这是计算的一个基本问题，不是ESLint或Prettier特别是。

所以我真的希望每个阅读本文的人都能理解自动化工具将永远无法修复您的代码。

但自动化工具仍然提供价值。

好消息
Rice定理可区分syntatic和语义的程序性能。粗略地说，句法是“它是如何写的”，而语义是“它的行为方式”。

大多数语法问题都可以轻松识别和修复。其中最著名的是缩进和换行符之类的东西。这些东西不会影响程序的行为，但确实为程序员创建了一致的语法标准。

它的语义属性是棘手的。

清晰的分离
因此，作为肉体的非自动化人类，我们应该对任何可以为我们自动化语法标准的事物感到非常满意。

另一方面，任何旨在解决语义问题的自动化工具都应该受到怀疑。这并不是说我们不应该使用这样的工具，而是赖斯定理告诉我们自动化永远不会发现所有问题，即使对于它确实发现的问题，它有时也会出错。因此，就我而言，每个语义问题的解决都需要人类参与。

过去
它曾经是句法和语义问题的首选ESLint工具。在许多代码库中它仍然是。但是随着 的兴起，越来越多的语法内容被. 我强烈认为这是一种有用的职责分离。PrettierPrettier

我的位置上的弱点
每个系统都是遗留系统。ESLint没有考虑到他们的 API Prettier。但他们确实在设计 API 时考虑到了一个非常可定制的插件系统，并包含了一个“修复”选项，插件可以实现该选项以提供对问题的自动更正。但如上所述，我相信这种自动修复应该只允许用于语法问题。我认为语法问题应该是Prettier修复的唯一责任，但肯定存在许多ESLint带有“可修复”规则的插件Prettier无法处理。

我没问题。

我的立场的弱点是程序员可能需要检查比严格理论上必要的更多的问题。但我宁愿有这种情况而不是另一种选择。

结束语
如果每个人都扫树叶，保持花园清洁就很容易了。

我认为作为技术书呆子，我们都对浮华并提出解决我们所有问题的宏伟计划感到非常兴奋。但是，即使是我们工作中乏味的部分，也有一种安静谦逊的态度。我们很容易相信我们编写的下一段代码将最终解决我们所有的问题。不幸的是，总会有树叶落在草地上。我们越早接受这一点，我们就能越早停止对自动化工具的持续失望。我见过的最好的代码库是由团队维护的，他们不试图炫耀，但非常关心每一行代码。如果每个人都被扫走了…工作永远不会完成，但幸好我喜欢它😄

唯一的问题是我需要每个人都像我一样享受扫树叶的乐趣。

无论如何，我有信心，如果我只说服我遇到的一小部分程序员采用这种思维方式，它将比我编写的任何一行代码产生更大的影响。