介紹
本指南與Flutter Coding Guidelines.搭配使用
編碼指南
- DO NOT 不要提交包含warning的代碼
- DO 遵循 S.O.L.I.D. code design principles
- DO 所有公開 API要寫清楚注釋
- DO NOT 不要寫輔助的靜態(tài)方法
- DO 所有異常案例需要寫單元測試
-
需要100% 測試覆蓋率
- 不要求覆蓋所有行, 但是所有邏輯分支需要覆蓋 (e.g., switch-case, if-else, etc.)
-
DO NOT 強制展開可選參數(shù)
- You can use optional-chaining, or validate that the content isn’t null
-
DO 移除你能看到的所有dead-code
- 項目不要出現(xiàn)任何注釋掉的代碼或者為用到的代碼
- 我們有g(shù)it版本記錄There’s no point thinking “Well, maybe we’ll use this function in the future”. We have commit history for a reason ;)
-
DO NOT 一些情況下不需要指定變量類型
- Rely on type-inference if the language supports this. Example:
-
Bad:
let theUltimateAnswer: int = 42
-
Good:
let theUltimateAnswer = 42
-
Bad:
- Rely on type-inference if the language supports this. Example:
- DO NOT 構(gòu)造函數(shù)盡量不要超過5個參數(shù)
-
DO NOT 不要忽略異常
- Otherwise, you are leaving land-mines for someone else to trip over someday
- DO NOT generically catch errors
- DO NOT 不要超出代碼行限制 (150 characters)
-
DO NOT 不要超出文件行數(shù)限制 (400 lines)
- Consider breaking up classes and files into smaller pieces, we don’t want huge, monolithic classes
-
DO NOT 函數(shù)參數(shù)類型要明確不要使用
Pair或其他類似- A nice alternative would be to create a model class, data class, or struct
命名規(guī)范
-
DO 命名要描述清楚
- “Clarity over Brevity”, we aren’t coding on CRT Monitors
- Examples:
| Bad: | Good: |
|---|---|
user.ser.excSrv() |
user.service.executeService() |
- DO 好的參數(shù)名相當(dāng)于注釋
-
DO 包含所有必要的單詞
- DO NOT include useless words, like type / class information
- Examples:
| Bad: | Good: |
|---|---|
var string1 = "Good one!" |
var successMessage = ... |
var string2 = "Ya don' goofed" |
var failureMessage = ... |
-
DO 布爾值讀起來像一個斷言
- Use a question format, such as “is/was/has…?”
- Examples:
| Bad: | Good: |
|---|---|
var done = false |
var isDone = false |
-
DO NOT 不要使用否定判斷命名
- This puts extra cognitive load on future developers
- Examples:
| Bad: | Good: |
|---|---|
var isNotDone = true, if isNotDone...
|
var isDone = false, if !isDone...
|
-
DO 使用命名慣例
- If there is common naming convention in a file or module, please follow the conventions
- This will help keep the codebase as coherent as possible
- If there is common naming convention in a file or module, please follow the conventions
-
DO NOT 不要使用縮寫
-
“Clarity over Brevity”
- Acronyms are okay though
-
class BmwPhevInfo { ...is better thanclass BayerischeMotorenWerkePluginHybridElectricVehicleInfo { ...
-
- Acronyms are okay though
- Examples:
-
“Clarity over Brevity”
| Bad: | Good: |
|---|---|
var usrIdx = 1 |
var userIndex = 1 |
