編寫自己的代碼規則

項目開發到一定階段，就需要投入資源構建代碼保護機制。這個時機難以精確定義，大致是在項目長期穩定運行，一些問題開始顯現，但尚未完全陷入混亂之前。避免過早優化，也避免，嗯，過晚優化。

一些工具非常易於實施，通常在項目早期就可應用。例如Prettier代碼格式化工具，能實時保持代碼規範。還有許多類似的工具，可在編碼過程中直接使用，比如可訪問性、兼容性、安全性的代碼檢查等等。 Webhint整合了大量此類工具，值得一試。

還有一些工具需要編寫更多代碼來保護你的代碼。測試是其中的重要部分，甚至可以設置為在編碼過程中運行。測試確保代碼按預期運行，因此具有極高的價值。

本文重點討論通過編寫更多代碼來保護代碼，但這並非傳統的測試，而是自定義代碼檢查規則。最近我接觸到兩篇關於自定義代碼檢查規則的文章：

• Benedict Quinn 的“如何編寫自定義ESLint規則”
• Omri Lavi 的“自定義Stylelint規則——編寫你的第一個規則”

我主要在代碼庫中使用ESLint和Stylelint。但需要提醒的是，我發現這兩個工具的自定義規則編寫過程相當複雜。你需要了解抽象語法樹(AST)。這與if (rules.find.selector.startsWith("old")) throw("Deprecated selector.")這種簡單的語句完全不同。

這讓我聯想到一個有趣的問題：

我們團隊正在維護一個舊項目，希望移除許多舊的、有問題的CSS選擇器。例如，有人打開HTML文件，看到一個class名為deprecated-selector的元素，我們的目標是讓IDE將其標記為代碼檢查錯誤，並提示“這是一個已棄用的選擇器，請使用.ui-fresh\_\_selector代替”。

我首先想到的是編寫一個自定義Stylelint規則，查找團隊已知的已棄用選擇器並發出警告。但不幸的是，Stylelint用於檢查CSS，而這裡的主要問題似乎在於HTML。我知道html-inspector可以編寫自定義規則，但它已經有點過時了，所以我不確定是否能成功。

以上是編寫自己的代碼規則的詳細內容。更多資訊請關注PHP中文網其他相關文章！