具備基本工程素養的同學都會注重編碼規範，而程式碼風格檢查（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 husky複製程式碼yarn 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-staged複製程式碼yarn 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
本文作者王仕軍，商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。如果你覺得本文對你有幫助，請點贊！如果對文中的內容有任何疑問，歡迎留言討論。想知道我接下來會寫些什麼？歡迎訂閱我的掘金專欄或知乎專欄：《前端週刊：讓你在前端領域跟上時代的腳步》。