介绍
本指南与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 一些情况下不需要指定变量类型
- 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
命名规范
- DO 命名要描述清楚
- “Clarity over Brevity”, we aren’t coding on CRT Monitors
- Examples:
Bad: | Good: |
---|
user.ser.excSrv() | user.service.executeService() |
- DO 好的参数名相当于注释
- 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
- 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 |