今天是美好的一天，因為我開始將 ESLint 整合到我們的程式碼庫中！我是一隻有趣的碼猴。我喜歡良好的編碼實踐，例如 linting、用戶/技術/產品文件、測試、可訪問性和安全性。這些主題通常優先於交付工作代碼，因為程式碼可以在沒有我列出的任何程式設計熱情的情況下工作。但是，如果實現了所有這些實踐，程式碼將很少被破壞（或被破壞），並且是更可靠的程式碼。為什麼不從一開始就創建「可靠的工作代碼」？
Linting 將幫助您儘早發現常見錯誤。 Linting 規則可以識別不良的編碼實踐，因此開發人員不會將它們引入專案中。例如，Linting 可以識別何時使用 const 而不是 let 或影子變數。
透過 linting 來防止不良程式碼，值得進行多次調試不良程式碼的衝刺。
我們有一個現有的程式碼庫，有許多開發人員做出了貢獻。在我安裝 ESLint 並執行報表後，程式碼有超過 5K 的 linting 違規。我尋找與 NextJS、TypeScript、A11y 和 JavaScript 一起使用的最佳 linting 規則。由於有這麼多的違規行為，我決定逐步尋找錯誤。 ESLint 具有自動修復功能，但永遠不要在預先存在的程式碼庫上運行該功能並期望它能夠運作。不，不，沒有年輕人。我們必須迭代！
我將關鍵規則設為“錯誤”，其餘規則設定為“警告”或“關閉”。然後我重新運行該報告，以確定在再次部署我們的程式碼之前應該修復哪些問題。在手動修復所有錯誤並且可以建立程式碼後，我運行了單元測試以確保我們仍然通過所有內容。良好的 linting 永遠不會破壞程式碼。 linting 充其量是為了支援開發人員。幫助初級開發人員學習更好的編寫程式碼的方法，因為他們必須這樣做。
在我的所有錯誤都被識別並修復或忽略之後，我們就可以部署並知道我們的程式碼與我們「今天」所能得到的一樣好。現在程式碼庫已經修復，我們將來可以使用“auto-magic-fix”，並相信它有 50/50 的機會來修復 linting 錯誤。
看來ESLint已經長大了！它將不再支援更多的程式碼格式化規則，這些規則應該由程式碼格式化程式庫而不是 linting 程式庫維護。自 v9 起，ESLint 已棄用許多功能，並將大部分（如果不是全部）移至 Stylistic！
我使用 Prettier 進行程式碼格式化，並且 Typescript 在 Stylistic 中具有標誌支持，因此我堅持使用 ESLint v8.53.0，這樣我就可以保持 ESLint 的卓越程式碼格式化。但我最終將不得不進入 9，所以這只是「把罐頭踢到路上」。
編碼快樂！
以上是代碼檢查的詳細內容。更多資訊請關注PHP中文網其他相關文章！
