别被虚幻的问题分散了注意力

代码风格查询、项目目录结构、代码美化

  • 人们习惯于将 linter 看作是一个过分热心又吵闹的看门人，而不是一个有用的工具。 有用的警告被风格提示的海洋淹没了。因此，人们在调试时不看 linter 的提示，错过有用的信息。此外，之前不太写 JavaScript 的人群（例如，设计人员）也因此更难使用代码。

  • 对于某种模式，大家不要太学着区分有效和无效的用法。

  • 最终，人们采用 “执法者心态”，对那些没带来有意义变化但在代码中易于发现的地方持批评态度。“你用了函数声明，但我们的项目用的是箭头函数。” 每次我有强烈意愿，想要强制执行类似的规则时，仔细想想就会发现，我把个人情绪投入到了这个规则中——然后又努力让这消失。这让我陷入虚假的成就感，而丝毫没有改进我的代码。

这个三个东西, 确实项目初期我一度被他们搞的很头疼。 直到项目架子差不多搭建完成的时候, 我才意识到 “他们” 真的没想象中的那么重要。

不要为了用而用, 认同大于约束

整理你的 Lint 配置

这条lint规则我们需要吗? 一条条过一下你们项目中启用的 lint 规则，接着问问自己：“这条规则有帮我找到过 bug 吗?” 如果不是，我们就该考虑应删掉这条规则。

至少，你的团队应该有一个流程，会去删除引起干扰的规则项。

不要假设一年前你或别人添加到你的 lint 配置中的任何东西，都是“最佳实践”。

它们中的许多都太微妙了，无法通过一条 lint 规则捕捉到。这就是为什么说，在团队成员之间建立信任，在 wiki 或简短的设计指南里分享有用的知识，是非常重要的事了。

代码格式化 我们在一个项目中确实需要它, 但是它确定有点烦人, 你可以需要阅读大量配置项, 当然你在配置的过程中不可避免会遇到坑, 本人就很有体会.。

本身的代码美学, 我此时的风格就是我写下的代码, 又何必要变。

不是一切都值得自动化！从 实际阅读 中获得的见解，这种指南中的理由可能比遵循 “规则” 更有价值。

如果遵循严格的风格指南是一种分心，那到底什么才是重要的呢？