具备基本工程素养的同学都会注重编码规范，而代码风格检查（Code Linting，简称 Lint）是保障代码规范一致性的重要手段，你的工作流中有 Lint 环节么？有的话你用的爽么？你在团队中推广过 Lint，但是大家都不买账？究竟是为啥？
Lint 是什么？
探讨怎么做之前，我们很有必要给 Lint 来个清晰、准确的定义，wikipedia 的定义如下：
In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.
简单来说，Lint 就是对代码做静态分析，并试图找出潜在问题的工具，实战中我们也用 Lint 来指使用工具的过程。
为什么要 Lint？
使用 Lint 会有什么好处呢？在我看来至少具有如下 3 点：
- 更少的 Bug，剑桥大学的研究发现，全世界每年因为软 Bug 造成的经济损失约 3120 亿美金；
- 更高的开发效率，工程师平均会花掉 50% 的工作时间定位和解决各种 Bug，其中不乏那些显而易见的低级错误，而 Lint 很容易发现低级的、显而易见的错误；
- 更高的可读性，代码可读性的首要因子是“表面文章”，表面上看起来乱糟糟的代码通常更难读懂；
可以毫不客气的说，如果你不做 Lint，就是在浪费自己的时间，浪费公司的资源。既然做 Lint 的预期效果很好？该怎么做呢？
提交后 Lint：反馈链条太长？
说到怎么做，多数人会自然而然的想到各种 Lint 工具，目前社区中针对各种语言都开发了 Lint 工具，前端能用到的就有大把：ESLint、Standard、SCSSLint、JSONLint、HTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是个非常不错的参考。
很多同学选择在持续集成阶段（后文用 CI 代称）做 Lint，比如使用远程的 Git Hooks 来触发。但是从实际的经历来看，这种做法的反馈链条通常如下：
代码提交 --> 发现问题(远程) --> 修复问题 --> 重新提交 --> 通过检查(远程)整个过程可能会浪费掉你不少时间，毕竟 CI 过程通常不仅是在做 Lint，如果你是那种不知道自己时间每天都去哪儿了的工程师，可以反思下自己或者团队的工作流是否是这样。并且，请相信我，你不是少数人。
你有没有这样的经历：吭哧吭哧写了几天代码，各种验收都通过了，最后被 CI 拒绝，竟是因为你的代码中少加了一个逗号，这时候心情简直崩溃到无法形容：
从 GitHub 上各种修复 Lint 的提交数量不难发现工程师在修复 Lint 问题上浪费的时间，比如搜索 "fix lint"，多达 45W 次提交：
再比如搜索 “fix indent”，多达 226W 次提交，是不是很触目惊心？
只在 CI 流程做 Lint 的缺点也是显而易见的：
- Lint 在整个开发工作流中的反馈链条太长，浪费时间、注意力和资源，最致命的；
- CI 流程搭建成本比较高，即使 Travis CI 这种服务，步骤也还是比较繁琐；
我们该怎么改进？
提交前 Lint：错误信息不相关？
为了缩短 Lint 的反馈链条，把 Lint 挪到本地是最有效的办法。常见做法是使用 husky 或者 pre-commit 在本地提交之前做 Lint。
使用 husky 的具体做法如下：
首先，安装依赖：
npm install -D huskyyarn add --dev husky
然后修改 package.json，增加配置：
{
"scripts": { "precommit": "eslint src/**/*.js" }}最后尝试 Git 提交，你就会很快收到反馈：
git commit -m "Keep calm and commit"但是在遗留代码仓库上工作的同学很快会遇到新的问题，开启 Lint 初期，你可能会面临成千上万的 Lint Error 需要修复。部分同学对下面这个图可能并不陌生：只改了文件 A，但是文件 B、C、D 中也有大量错误。
把整个仓库都格式化不失为一种选择，但是实际上需要很大的勇气。多数人在项目中运用新工具都希望是渐进式的，而不是推到重来式的，因为相比而言，业务系统稳定是更重要的事情。简单的把 Lint 挪到本地，反馈链条是缩短了，但是面对每次改动，工具还是给出了太多不相关的信息，这无疑与小步快跑的互联网节奏是相违背的。
该怎么破？
只 Lint 改动的：66666
如果把 Lint 挪到本地，并且每次提交只检查本次提交所修改的文件，上面的痛点就都解决了。Feedly 的工程师 Andrey Okonetchnikov 开发的 lint-staged 就是基于这个想法，其中 staged 是 Git 里面的概念，指待提交区，使用 git commit -a，或者先 git add 然后 git commit 的时候，你的修改代码都会经过待提交区。
lint-staged 用法如下：
首先，安装依赖：
npm install -D lint-stagedyarn add --dev lint-staged
然后，修改 package.json 配置：
{ "scripts": { "precommit": "lint-staged" }, "lint-staged": { "src/**/*.js": "eslint" }}最后，尝试提交的效果：
实际上，lint-staged 给了你提交前代码操作的更大自由度，比如使用下面的配置，自动修复错误：
{ "scripts": { "precommit": "lint-staged" }, "lint-staged": { "src/**/*.js": ["eslint --fix", "git add"] }}或者使用下面的配置，自动格式化代码（谨慎使用）：
{ "scripts": { "precommit": "lint-staged" }, "lint-staged": { "src/**/*.js": ["prettier --write", "git add"] }}此外，lint-staged 和 prettier 已经集成到 create-react-app 中了。你是不是也应该好好打磨下自己的 Lint 工作流了？
总结
有人说前端攻城狮是世界上最奇怪的动物，提交代码时用 prettier 把代码排版的很美观，但部署上线时又使用 uglify 把代码压缩的连亲妈都不认了，事实是，如果我们写出来的代码本来就很丑陋，就根本不需要用 uglify。希望读到这里的你能把 Lint 工作流打磨到极致，把更多时间专注在解决真正的问题上，成为真正高效的工程师。
One More Thing
本文作者王仕军，商业转载请联系作者获得授权，非商业转载请注明出处。如果你觉得本文对你有帮助，请点赞！如果对文中的内容有任何疑问，欢迎留言讨论。想知道我接下来会写些什么？欢迎订阅我的掘金专栏或知乎专栏：《前端周刊：让你在前端领域跟上时代的脚步》。
