搭建企业级app架构(3)-开发规范

介绍

本指南与👉Flutter Coding Guidelines.搭配使用

编码指南

• DO NOT 不要提交包含warning的代码
• DO 遵循 S.O.L.I.D. code design principles
• DO 所有公开 API要写清楚注释
• DO NOT 不要写辅助的静态方法
• 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 一些情况下不需要指定变量类型
  • Bad:
  • Good:
  • let theUltimateAnswer: int = 42
  • let theUltimateAnswer = 42
  • Rely on type-inference if the language supports this. Example:
• 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

命名规范

• 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 使用命名惯例
  • 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 不要使用缩写
  • Acronyms are okay though
  • class BmwPhevInfo { ... is better than class BayerischeMotorenWerkePluginHybridElectricVehicleInfo { ...
  • “Clarity over Brevity”
  • Examples: