flutter搭建企業(yè)級(jí)app架構(gòu)(3)-開發(fā)規(guī)范

介紹

本指南與Flutter Coding Guidelines.搭配使用

編碼指南

  • DO NOT 不要提交包含warning的代碼
  • DO 遵循 S.O.L.I.D. code design principles
  • DO 所有公開 API要寫清楚注釋
  • DO NOT 不要寫輔助的靜態(tài)方法
  • DO 所有異常案例需要寫單元測(cè)試
  • 需要100% 測(cè)試覆蓋率
    • 不要求覆蓋所有行, 但是所有邏輯分支需要覆蓋 (e.g., switch-case, if-else, etc.)
  • DO NOT 強(qiáng)制展開可選參數(shù)
    • You can use optional-chaining, or validate that the content isn’t null
  • DO 移除你能看到的所有dead-code
    • 項(xiàng)目不要出現(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
  • DO NOT 構(gòu)造函數(shù)盡量不要超過5個(gè)參數(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 布爾值讀起來像一個(gè)斷言
    • 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
  • DO NOT 不要使用縮寫
    • “Clarity over Brevity”
      • Acronyms are okay though
        • class BmwPhevInfo { ... is better than class BayerischeMotorenWerkePluginHybridElectricVehicleInfo { ...
    • Examples:
Bad: Good:
var usrIdx = 1 var userIndex = 1

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容