動態

詳情 返回 返回

Dart 3.7格式化工具“亂改代碼”?強迫症必看 - 動態 詳情

哈嘍,我是老劉

一個從事軟件開發10年+,Flutter開發7年的程序員。

前兩天有個朋友諮詢升級到Flutter 3.35後的格式化問題。

簡單來説就是升級到Flutter 3.35(基於Dart 3.7以上)後,格式化後的代碼與之前的版本不同。

原先多行的代碼,格式化工具會自動刪除結尾的逗號,導致代碼合併成為一行。

舊版本

新版本

其實這個是Dart 3.7引入的新特性,如果代碼比較短就合併成一行。

老劉自己在開發中的習慣也基本是符合這個邏輯的,短的代碼一行,長的代碼分行,所以沒有太大的感知。

但是有人問起來我就也向團隊的小夥伴們問了一下,發現還是不少人對這個新的格式化方案挺彆扭的。

主要是他們不管長短都喜歡多行的樣子。(話説你們強迫症挺嚴重的)

因此今天寫篇文章來分享一下這個問題的解決方案。


Dart 3.7版本新的格式化邏輯

首先格式化的基本邏輯是如果有尾隨逗號,格式化器會將其拆分為多行;如果移除尾隨逗號,格式化器會將列表合併成一行。

這一點在新舊版本上是一致的。

而Dart 3.7引入了新的格式化風格,會根據代碼是否超出最大頁面寬度自動決定是否添加尾隨逗號。

如果代碼比較短,格式化器會自動移除尾隨逗號,從而格式化為一行。

如果代碼很多,超出了最大頁面寬度,格式化器會自動添加尾隨逗號。也就會自動格式化成多行。


解決方案

解決方案1:調整頁面寬度

通過設置最大頁面寬度,可以調整格式化器的行為。

analysis_options.yaml文件中設置一個比較小的值就可以讓大多數列表都格式化成多行。

# analysis_options.yaml
formatter:
  page_width: 80

但是這種方案仍然是格式化工具自動決定是否添加結尾的逗號。

如果強迫症患者想強制格式化工具添加結尾的逗號,來看方案2。

解決方案2:

從Dart 3.8開始,你可以通過配置analysis_options.yaml文件來恢復舊的格式化行為

# analysis_options.yaml
formatter:
  trailing_commas: preserve

這個配置會保證格式化工具不會修改結尾的逗號,由程序員決定是否添加。

注意需要Dart 3.8以上才支持這個選項,因此為了方便下面我列出了Flutter版本對應的Dart版本,看看你是否需要升級。


Flutter對應dart版本

下表列出了 Flutter 3.0 及以上穩定版本與其對應的 Dart 版本(以主/次版本對齊,補丁用 x 表示):

Flutter Dart
3.0.x 2.17.x
3.3.x 2.18.x
3.7.x 2.19.x
3.10.x 3.0.x
3.13.x 3.1.x
3.16.x 3.2.x
3.19.x 3.3.x
3.22.x 3.4.x
3.24.x 3.5.x
3.27.x 3.6.x
3.29.x 3.7.x
3.32.x 3.8.x
3.35.x 3.9.x

説明:

  • Flutter SDK 自帶固定的 Dart 版本,隨 Flutter 一起升級。
  • 不同的 3.xx.y 小版本通常對應同一 Dart 主/次版本(例如 3.35.0、3.35.5 都是 Dart 3.9.x)。
  • 實際本地版本以命令行輸出為準:運行 flutter --version 可同時查看 Flutter 和 Dart 的具體版本。

參考:

  • Flutter SDK archive(官方歸檔,列出每個 Flutter 版本對應的 Dart 版本):https://docs.flutter.dev/install/archive

總結:“智能”的邊界在哪裏?

Dart 團隊的初衷是好的:讓短代碼更緊湊,長代碼自動換行,這符合一般的美學原則。

但問題在於,代碼的可讀性是主觀的,尤其是在 Flutter 這種聲明式 UI 框架中,開發者經常利用換行來組織視覺層級,即便只有兩三個屬性,也可能希望它們垂直對齊,以模仿最終的 UI 結構。

當工具的智能越過了開發者的習慣邊界,就會產生摩擦。

這裏 Dart 團隊的成熟反應值得稱讚,在 3.8 版本中迅速加入了 trailing_commas: preserve 選項。

這是一個成熟的開源社區和工具團隊應有的表現。他們傾聽了社區的聲音,並認識到在這種場景下,保留開發者的明確意圖比工具的自動猜測更重要。

這在自動化和控制權之間找到了一個完美的平衡點: 默認智能處理,但允許開發者自己配置。

更進一步來説,我們正在進入 AI 編程時代,AI Agent 會進行更大膽、更自動化的代碼生成和修改。

這個小小的逗號問題,其實是對未來 AI 工具設計者的一個警示:

  • AI 不能是一個黑盒:AI 助手不僅要完成任務,還要能讓開發者理解它的決策邏輯。
  • Agent必須可配置:開發者需要能夠訓練或配置AI,比如讓Agent的代碼風格、架構模式與團隊現有規範保持一致。
  • 永遠需要一個手動微調的選項 :AI 提供的解決方案必須是可審查、可修改的,最終的控制權必須掌握在開發者手中。

好了,如果看到這裏的同學對客户端開發或者Flutter開發感興趣,歡迎聯繫老劉,我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》,覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。

覆蓋90%開發場景的《Flutter開發手冊》

Add a new 評論

Some HTML is okay.