flutter/dart 程式碼 規範 翻譯 加自我理解
前言
最近看qq群裡發的很多程式碼截圖,感覺命名規則/檔案命名都不符合規範
很多朋友都是從其他語言轉向dart/flutter的,深感語言環境還需要大家共同去維護,建議還是規範化程式碼,這樣所有人看著都會舒服
恰好dart語言官方有自己的程式碼規範和相關的說明,在dartlang官網上,英文好的建議閱讀原文
連線地址 https://www.dartlang.org/guides/language/effective-dart/style
我這裡僅粗略翻譯和加入一些自己的理解
圖片均來自於上述url對應的頁面中
當前dart版本為2.0版本,日期為2018年08月22日
可能會在未來有改動,到時請以最新文件為準
文件中圖片的綠色部分為正例,右上角帶good標識
紅色是反例,右上角帶bad標識
標識方案
在dart有3種常規標識方案
第一個為大寫字母開頭的駝峰式 如 UserInterface 每個詞的首字母為大寫
第二個是小寫開頭的駝峰式,如testRun,第一個單詞是小寫,後續每個單詞首字母大寫
第三個是每個單詞均為小寫,以下劃線分隔,如user_response
總結
如果不想往下看具體的圖片和翻譯,直接看這裡
檔名: 小寫+下劃線
型別名(類名,函式型別名):大寫開頭駝峰
變數名(包含const final 常量):使用小寫開頭駝峰, 專案有特殊要求 const可以使用大寫+下劃線的方式,如同java
導包as後的名稱為小寫+下劃線
不要用匈牙利命名法中的kXXXX 這樣的命名方式,應該去掉k
超過兩位的英文縮寫一律按該單詞為普通小寫單詞處理,使用小寫
導包有順序要求,且每"部分"間空行分隔開,每部分內按字母排序,按如下順序排序
dart sdk內的庫
flutter內的庫
第三方庫
自己的庫
相對路徑引用
先全部import再export,不要交替進行
使用dartfmt工具格式化dart檔案程式碼 dartfmt -w lib/ flutter可以用flutter format lib
單行字元建議不要超過80個
流程控制語句無論如何都使用花括號包裹,即使只有單行
格式化個人建議:
建議不要使用idea/as/vscode 的自動儲存格式化作為交付
因為idea/vs有自己的格式化工具,並不是使用的dartfmt,這樣會造成程式碼交付格式不統一,寫程式碼過程中可以使用以方便提高閱讀性,但每次程式碼commit前建議使用 dartfmt -w lib/ 來格式化程式碼,以便於專案程式碼風格的統一,flutter使用者使用 flutter format lib
型別名稱
適用於類名,註解名,typedef定義的函式名
這裡有一個特例,當你的註解是一個const的常量時,使用@foo的方式作為註解
庫名稱,檔名用小寫+下劃線
使用小寫+下劃線方式命名library,檔名
原因如下:
某些檔案系統不區分大小寫，因此許多專案要求檔名全部為小寫。使用分隔字元允許名稱仍以該形式可讀。使用下劃線作為分隔符可確保名稱仍然是有效的Dart識別符號
匯入時
當匯入包時, 如果涉及到as, 一律使用小寫+下劃線方式
其他識別符號
包含頂級成員,類成員,方法內成員,引數名,命名引數名,一律使用小寫駝峰式
常量名稱
建議使用小寫駝峰式命名
但是你的專案中如果使用大寫+下劃線分割單詞的方式,則可以繼續使用這種方式
這裡有個小說明:最初dart中採用的大寫+下劃線方式,但是後來有一些變數需要修改為非const變數,就需要修改為小寫駝峰式,後一律使用小寫駝峰式
縮寫相關
超過兩位的使用常規方式,兩位以內使用大寫
在小寫駝峰式中,會出現一些約定俗成的縮寫,如http ftp io等,這些在英文詞法中都應該是大寫,但大寫連續會破壞可讀性,如HTTPSFTP,你不知道是HTTPS FTP 還是 HTTP SFTP,所以採用如上圖綠色的方式來命名
不要使用字首字母
匈牙利命名法中使用縮寫開頭的小寫駝峰命名法時,是因為當時編輯器無法很好幫助理解你的程式碼,這樣命名法能夠很好的幫助你去理解程式碼,現在dart語言中,編輯器可以很好的通過宣告等方式幫你理解你的程式碼,故,不要使用字首字母,如上圖綠色
規定程式碼的順序
為了使檔案保持整潔，我們有一個規定程式碼順序。每個“部分”應該用空行分隔。
保證dart的匯入順序在所有其他包之前
保證帶包名的引用方式在相對路徑引用之前
首先import第三方的包
匯入自己的包在後面一個單獨的部分
全部匯入完畢後,再export 匯出
每個部分按字母順序排序
格式化
使用dartfmt 程式來格式化程式碼
單行長度為80字元
可讀性研究表明，長行文字難以閱讀，因為當你移動到下一行的開頭時，你的眼睛必須走得更遠。這就是報紙和雜誌使用多列文字的原因。
如果你真的發現自己想要超過80個字元的行，我們的經驗是你的程式碼可能過於冗長而且可能更緊湊。主要罪犯通常是VeryLongCamelCaseClassNames。問問自己，“該型別名稱中的每個單詞是否告訴我一些關鍵或防止名稱衝突？”如果不是，請考慮省略它。