前言

Lint 是靜態程式檢查語法的工具，最早出現於 C 語言，也有人稱為 Code Quality Tools，主要是用來標記程式碼中含有某些可疑、不具結構性或潛在問題的部分，也因只標記緣故，所以只會透過編輯器提醒使用者。之後則汎用於各個語言之中，如 ESSLint、flake8、Rubocop…

從前在改以前寫程式時都會有幾個問題，『排版好亂』、『這變數(a1)是？』諸如此類的問題，但就在加入社群後認識很多圈內的朋友並與之討論後才體悟到 Lint 的重要性，首先在跟人家解釋程式時從變數、函式名稱時就能讓對方更快速知道用途，透過 Lint 的提醒讓我修正而不用與其他人解釋 a1 a2 個別代表什麼，大大的降低溝通成本。

優點

開發風格統一
不會有 tab、space 的問題
後續接手的人心力可以放更多在商業邏輯上
培養命名習慣，更謹慎地處理

缺點

容易打擊剛加入開發領域的朋友
- Ａ：明明邏輯是對的但怎麼紅字一堆？
設定太嚴謹時會為了修問題延誤邏輯開發時間
- 時程很趕但 CI 一直擋住

介紹

以下會介紹三個我使用過的 Lint，並分享使用經驗。

SonarQube

SonarQube 是我在之前的公司時所使用的 Lint，裡面的功能真的很完整，除了一些基本檢查以外，最有印象的就是它會找出淺在風險、Code 品質、花多久時間可以看懂…很多很特別的部分，也許這些功能可能只是參考，但看著數字很淒慘時工程魂就會上身，想要把它數值降低點別出現這麼可怕的數字 😅。

Azure + Sonar 參考董老師的影片

免費版具有容量限制，若是團隊人多的話我認為值得花錢買的 Lint，讓大家 Commit 的程式碼可以被檢查，而 SonarQube 應該是我目前遇到數一數二真的是在鞭打我 code 的一個凶狠 Lint 工具…

ESLint

起初我初學 Vue 時，在初始化專案時覺得是工程師就是要 Lint，就直接選 ESLint，且當時對於 config 設定檔一竅不通，因此除了執行時滿滿的錯字以外，也讓我對於寫 code quality 的成就感大大折損，對於 coding 年紀還年輕的朋友可以先養成對於 coding 有興趣後再來使用 Lint 我認為對於整個發展會比較健全(但還是看人)。

接著過了一陣子後，我開始修改一個 side project - Twitch-Bot，這時期因參加社群一陣子也得知 Bottender 這個使用 Javascript 開發 Chatbot 框架，就依照 Bottender 的初始化方式加上 ESLint，並且搭配 TypeScript 動態檢查所有 code。

可以看當時的 PR 連結，讓其他人改 code 時也是透過一樣的方式來貢獻，就不會有太多檔案被修改的問題了。

在一開始因為還不熟悉 Javascript 相關開發風格，而我使用很多 pythonic 的方式撰寫 Bot，導致整個專案被狠狠教訓了一遍，不過藉由 Lint 校正的好處是讓我再隔一段時間回來時修改 issue 時不會因為 coding style 不統一而引發的問題，再開發的過程中也會透過小蚯蚓告訴你命名或是哪邊有排版問題，只要遵守 Lint 的規則整份 code 沒有被標記起來就覺得神清氣爽 😆。

以下節錄我的 VSCode ESLint 相關設定：

{
  // 儲存時 format
  "editor.formatOnSave": true,

  // 單引號設定
  "javascript.preferences.quoteStyle": "single",
  "typescript.preferences.quoteStyle": "single",

  // ESLint 設定
  "eslint.autoFixOnSave": true,
  "eslint.enable": true,
  "eslint.validate": ["javascript", "typescript"],
  "eslint.format.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

參考我的 Gist

Bonus - VSCode settings

開啟編輯器後的左上角按下喜好設定，英文則是 Performance

接著右上角有個轉換檔案的圖案按下去就可以看到 setting.json 囉！

Flake8

當初會知道怎麼使用 Flake8 的原因是我去貢獻 LINE SDK，它們是使用 tox 來跑多版本的檢查(py2.7、3.4~3.7)，並透過 tox.ini 的設定來來制定使用的 Lint 及其相關設定(ignore…)。

以我前一陣子的寫的 Lotify 來說，在每次的上版前都一定要跑 flake8 檢查：

1	python -m pytest --flake8 tests/

上述範例是跑測試時要搭配 flake8 的格式。

透過 flak8 的檢查讓我在 CI 環境時就可以檢查出錯誤，規範貢獻者們的開發風格(包含自己)，如此一來過陣子再回來修改 Lotify 時就可以駕輕就熟 😆，且其他的貢獻者也可以遵守這個規範下去開發。

結論

Lint 是集結各方工程師們的血汗結晶所產生的規則，在這開源的時代跟著大家的規則走能減少許多溝通成本，讓心思可以在(商業、工程)邏輯上。另一部分我則認為是對自我的要求，透過固定的格式再經過 N 週/月 後會來看 code 時不會因為一直因為不統一的 coding style 而導致連自己都看不懂的程式碼窘境，因此適當地遵循也是會對以後開發更有幫助喔！

每個工具沒有絕對的好壞，我認為適當的遵循是好的，但別一昧的堅持才能開發出好的程式碼。

忍者工坊

我從 Lint 中學到了什麼？

前言

優點

缺點

介紹

SonarQube

ESLint

Bonus - VSCode settings

Flake8

結論