原文地址：flutter-explained.dev/blog/flutte…
原文作者：flutter-explained.dev/blog/author…
釋出時間：2021年1月4日
我們在Flutter最佳實踐視訊中介紹的最佳實踐之一是Flutter程式碼分析和Linting。我想開始一個小系列的不同的部落格文章，在那裡我們談論這些最佳實踐中的每一個，今天我們從第一個開始。程式碼分析和提示。
為Flutter專案設定程式碼提示功能
首先，我想說的是，Flutter中的額外Linting是一個有爭議的話題。一方面，許多人喜歡程式碼提示，因為它使我們能夠關注程式碼的關鍵部分。然而，有些人不喜歡它，因為它限制了他們，導致錯誤的構建錯誤。但在我們開始討論之前，讓我們先說說什麼是程式碼提示，以及我們如何充分使用它的潛力。
程式碼提示是一種自動驗證你的程式碼是否正確的方法。在我們的日常工作中，總是有一個林特，我們都在使用。在VSCode和Android Studio這樣的編輯器中，當我們的程式碼無法執行時，我們會收到錯誤。構建錯誤的視覺化已經是我們的Linter的功能了。這個整合的Code Linter是一個檢查你的程式碼是否存在構建問題的工具，這意味著你甚至不可能執行你的應用程式。我們不必在我們的程式碼中尋找錯誤，當一切正常時，我們確信我們的程式碼是可執行的。
感謝現代工具，我們可以擴充套件這些規則，檢查我們當前的專案，而不僅僅是破損的程式碼。例如，我們可以告訴我們的Linter，我們要檢查錯誤的程式碼樣式。在Dart和Flutter中，額外的lint規則是由一個叫做analysis_options.yaml的檔案管理。如果你沒有聽說過yaml副檔名，它只是一種方便的檔案結構方式，允許你用兩個空格建立樹狀結構。請隨時在這裡閱讀更多關於.yaml副檔名的資訊。
我們的任務。在我們的專案中強制執行單引號
讓我們假設我們會強迫所有的開發人員在我們的專案中工作，每一個字串都應該用單引號來完成。我們的IDE應該立即顯示出來，就像下面的圖片。
我們的結果示例
為了讓Dart和Flutter的靜態程式碼分析器識別這個錯誤，我們必須建立一個analysis_options.yaml，負責為整個專案提供Dart分析器的指令，在後臺執行並驗證我們的程式碼。我們可以在我們專案的根部建立analysis_options，大多數IDE，如Android Studio或Visual Studio Code會立即理解它需要做什麼。現在，讓我們仔細看看analysis_options檔案。在analysis_options中，我們可以修改分析器和linter的行為。
分析器和襯墊器
在常見的analysis_options.yaml檔案的第一部分，通常是分析器。在這裡，我們可以配置更多關於如何檢查我們程式碼的一般部分。首先，我們可以設定是否要顯示錯誤、警告，或作為特定規則的資訊。其次，我們可以將檔案和資料夾排除在檢查系統之外。此外，我們還可以忽略特定的規則。最後但並非最不重要的是，我們有機會引入額外的嚴格的型別檢查和實驗性行為，如無慢速檢查或超級混合器。
現在要使用我們註冊給分析器的主要資訊，我們必須指定我們要在我們的專案中應用的規則。因此，我們使用analysis_options.yaml的Linter部分。在linter部分，我們定義哪些規則將應用於我們的專案。大約有180條規則，你可以指定並使它們在你的應用程式中立即可見。如果要解釋的話，所有的規則都會佔用這篇博文的篇幅，所以請隨時檢視Linter for Dart網站上你可以指定的提示規則列表。
潤色規則
在我寫這篇文章的時候，有三個不同類別的提示規則。首先是錯誤規則，它們是可能的編碼錯誤。第二，我們有風格規則，定義程式碼風格事項，如單引號或雙引號。它並不提示你的程式碼是否穩定，但它有助於對齊整個程式碼庫。pub規則遵循這兩點。這套規則定義了一個pub包必須的行為方式；它只包括兩條規則，即如何在你的pubspec.yaml中命名包和排序依賴關係。
avoid_init_to_null
正如名字已經說明的那樣，通過這條林特規則，你不再允許用null來初始化變數。但為什麼這樣做會有幫助呢？在Dart中，每個沒有指定值的變數都會被自動設定為null。沒有空記憶體的概念，也沒有任何其他我們可能陷入的陷阱。考慮到這一點，特別宣告一個變數為null只會使我們的程式碼變得臃腫，而且是不必要的，不需要的。
在明確宣告為null時，linter會顯示一個資訊
use_string_buffers
另一個奇妙的規則，許多開發者並沒有真正意識到，它是一種更高效能的串聯字串的方式。字串緩衝器可以幫助你改善字串的連線，並允許你以最有效的方式進行連線。為了確保你的程式碼中的所有貢獻者都能有效地連線字串，我們可以設定use_string_buffers樣式規則。
如果你可以使用一個StringBuffer，Linter會顯示一個警告
StringBuffer提供了一種處理字串的高效能方法
prefer_double_quotes
首選雙引號規則允許你控制你想要執行的特定引號樣式。在我們的程式碼庫中，我們更喜歡雙引號，但也存在單引號規則，這使得我們可以強制執行引號樣式。如果你在一個多語言團隊中工作，這尤其有幫助，因為各國的鍵盤佈局不同。相比之下，在英語和美語國家，單引號更容易使用，而且在其他國家，如德國，通常更喜歡使用雙引號。這條規則使得維護者或包或專案的擁有者在一般情況下希望如何工作的資訊變得清晰。
喜歡雙引號的規則導致了關於雙引號用法的資訊
這也是我們要用來解決我們的問題的規則，並在整個專案中強制使用雙引號。
解決方案
好了，現在我們知道了Linter和Analyzer是如何工作的，讓我們來解決這篇博文的目標，我們要強制每個在我們程式碼庫上工作的開發人員喜歡雙引號，如果他們不這樣做，我們要把它真正顯示為一個錯誤。我們要做的第一件事是用問題的正確嚴重程度來定義分析器。在我們的例子中，這將是 "錯誤"。接下來，我們在pubspec.yaml中定義了我們要新增的新規則的linter。
分析器和執行緒
現在，在我們指定了規則和執行的嚴重程度後，我們已經可以在IDE中看到錯誤出現了。
設定了正確的規則後出現的提示錯誤
如果我們現在在專案中的終端執行dart analyze，我們會收到一份完整的分析報告。現在我們可以在我們的終端中使用這個命令。如果我們現在在CI/CD鏈中使用這個命令，構建將失敗，我們的團隊將不得不修復它以合併到我們的專案。
作為一個包的Lint規則
像往常一樣，有一些神奇的包，它們帶有預定義的規則選擇，使你更容易設定你想在專案中使用的第一個基線。讓我們先來看看如何在我們的專案中包含它們。
安裝一個第三方的提示規則集
為了新增一個品評規則集，我們必須首先在pubspec.yaml中新增對pub.dev包的依賴。舉個例子，我們想把Lint包新增到我們的專案中。
將Lint新增到我們的dev依賴項中
下一步是將包中的規則匯入我們的analysis_options.yaml中。
將lint包的analysis_options新增到我們專案的analysis_options中
只要你現在開啟不同的檔案，你就會發現，軟體包的linting規則已經被考慮到了，並且可以使用了。讓我們假設你不喜歡某個規則。你可以通過包括林特和分析器輕鬆地覆蓋該行為。你的規則將覆蓋軟體包的規則，這樣你就能一直控制提示的內容。
覆蓋特定規則的完整解決方案
潤色包
Lint包的標誌
Pascal Welsch建立了第一個Lint包，它包括Flutter和Dart專案的lint規則的基線。如果你使用這個包，你可以事後擴充套件或排除規則，但它是用消費者建立的。這意味著如果你不一定在Flutter專案上工作。這應該是你的方法。
Pedantic
我想向你介紹的第二個包是所謂的pedantic包。Flutter團隊建立了迂迴包來支援一套規則，這套規則通常在使用和允許方面有更多的限制，並且不時地有點過度工程化。
總結
在這篇文章中，我們學習瞭如何將Linting規則用於我們的優勢，並執行規則，以便每個與我們合作的開發者以相同的方式工作。生成這些規則並在團隊中討論它們可能是很乏味的，很多人會說這是不值得的。但是，如果現在開始對話和討論，你就有合適的工具加入討論並給出一些有價值的見解。
謝謝你的閱讀，請在下面的描述中告訴我你對Linting規則的看法!