介紹

本指南與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 強制展開可選參數
  • You can use optional-chaining, or validate that the content isn’t null
• DO 移除你能看到的所有dead-code
  • 項目不要出現任何注釋掉的代碼或者為用到的代碼
  • 我們有git版本記錄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
• DO NOT 構造函數盡量不要超過5個參數
• 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 不要超出文件行數限制 (400 lines)
  • Consider breaking up classes and files into smaller pieces, we don’t want huge, monolithic classes
• DO NOT 函數參數類型要明確不要使用 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:

• DO 好的參數名相當于注釋
• DO 包含所有必要的單詞
  • DO NOT include useless words, like type / class information
  • Examples:

• DO 布爾值讀起來像一個斷言
  • Use a question format, such as “is/was/has…?”
  • Examples:

• DO NOT 不要使用否定判斷命名
  • This puts extra cognitive load on future developers
  • Examples:

• 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
• DO NOT 不要使用縮寫
  • “Clarity over Brevity”
    • Acronyms are okay though
      • class BmwPhevInfo { ... is better than class BayerischeMotorenWerkePluginHybridElectricVehicleInfo { ...
  • Examples: