这是我参与「第五届青训营 」伴学笔记创作活动的第 2 天
1.1 简介
什么是高质量？
正确可靠、简洁清晰
- 各种边界条件是否考虑完备？
- 异常情况处理，稳定性保证
- 易读性维护
编程原则
- 简单性
- 可读性
- 生产力
1.2 编码规范
如何编写高质量的Go代码
- 代码格式
- 注释
- 命名规范
- 控制流程
- 错误和异常处理
公共符号始终要注释
有一个例外，不需要注释实现接口的方法。
1.2.1 代码格式
gofmt
goimports
1.2.2 注释
注释应该做的：
- 解释代码作用
- 解释代码如何做的
- 解释代码实现的原因
- 解释代码什么情况会出错
代码是最好的注释，注释应提供代码未表达出来的上下文信息。
1.2.3 命名规范
变量命名
- 简洁胜于冗长
- 缩略词全大写，但当其们位于变量开头且不导出时，使用全小写
- 变量距离其被使用的距离越远，则需要使用越多的上下文信息。
函数命名
- 函数名不需要携带包名的上下文信息。
- 函数名尽量简短
- 当名为foo的包的某个函数返回类型Foo时，可以省略类型信息
- 当名为foo的包的某个函数返回类型T时，可以在函数名中加入类型信息。、
包命名
- 只由小写字母组成，不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息
- 不要于标准库同名
尽量满足
- 不要使用变量名作为包名
- 使用单数而不是复数
- 谨慎使用缩写
小结
核心目标是降低阅读理解代码的成本
重点考虑上下文信息，设计简洁清晰的名称
1.2.3 控制流程
- 避免嵌套，保持正常流程清晰
- 尽量保持正常代码路径为最小缩进(异常情况提前返回)
小结
- 线性原理，处理逻辑尽量走直线
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
1.2.5 错误和异常处理
简单错误
仅出现一次的错误，且在其他地方不需要捕获该错误
优先使用errors.New来创建匿名变量来直接表示简单错误
如有格式化的需求，使用fmt.Errorf
错误的Wrap和Unwarp
错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链
return fmt.Errorf("reading srcfiles list: %w", err)
(在fat.Errorf中使用%w将一个错误关联至错误链中)
错误判定
error.Is：判断错误链上的所有错误中是否含有特定错误
error.As：提取出错误链中的特定错误
panic
- 不建议在业务代码中使用panic
- 调用函数不包含recover会造成程序崩溃
- 若问题可以产被屏蔽或解决，应用error代替panic
- 当程序启动阶段发生不可逆转的错误时，可在init或main函数中使用panic
recover
-
recover只能被defer的函数中使用
-
嵌套无法生效
-
只在当前goroutine有效
-
defer的语句是后进先出
-
如果需要更多的上下文信息，可以recover后在log中记录当前调用栈
小结
- error 尽可能提供简明的上下文信息链，方便定位问题
- panic用于真正异常的情况
- recover生效范围，当前goroutine的被defer的函数中生效
