这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记。

高质量编程

什么是高质量

  ——编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码

代码格式

 推荐使用gofmt自动格式化代码。

代码注释

• 注释应该解释代码作用。

• 注释应该解释代码是如何做的。

• 注释应该解释代码实现的原因。

• 注释应该解释代码什么情况会出错。

• 公共符号始终要注释。 注意：不需要注释实现接口的方法

小结：

• 代码是最好的注释。
• 注释应该提供代码为表达出的上下文信息。

 “好代码有很多注释，坏代码需要很多注释”

命名规范

variable

• 简洁 > 冗长。

• 缩略词全大写，但位于开头且不需要导出时，全小写。

• 变量距离被使用的地方越远，需要携带越多的上下文信息。

例子：for循环中 index => i。

function

• 不需要携带包名的上下文信息。

• 尽量简短。

• 当名为foo的包的某个函数返回类型Foo时，可以省略类型信息而不导致歧义。

• 当名为foo的包的某个函数返回类型T时，可以在函数名中加入类型信息。

package

• 只用小写字母。

• 简短包含一定的上下文信息。

• 不要与标准库同名。

---

以下规则尽量满足，以标准库包名为例：

• 不使用常用变量名作为包名。例如使用bufio而不是buf。

• 使用单数而不是复数。例如使用encoding而不是encodings。

• 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短。

小结：

• 核心目标是降低阅读成本。
• 重点考虑上下文，设计简洁清晰的名称。 "好的命名就像一个好笑话。如果你必须解释它，那就不好笑了"

控制流程

• 避免嵌套。

• 尽量保持正常代码路径为最小缩进。

小结：

• 线性原理，避免复杂的嵌套分支。
• 正常流程代码沿着屏幕向下移动。
• 提升代码可维护性和可读性。
• 故障大多处在复杂的条件语句和循环语句中。

---

错误和异常处理

简单错误

• 仅出现一次的错误，且在其他地方不需要捕获该错误。

• 优先使用errors.New来创建匿名变量来直接表示简单错误

• 如果有格式化要求，使用fmt.Errorf

错误的Wrap和Unwrap

• 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成了一个error的跟踪链。

• 在fmt.Errorf中使用：%w关键字来将一个错误关联至错误链中。

错误判定

• 判定一个错误是否为特定错误，使用errors.Is。

  • 不同于使用==，该方法可以判定错误链上的所有错误是否含有特定的错误。

• 在错误链上获取特定种类的错误，使用errors.As。

panic

• 不建议在业务代码中使用panic。

• 调用函数不包含recover会造成程序崩溃。

• 当程序启动阶段发生不可逆转的错误时，可以在init或main函数中使用panic。

recover

• recover只能在被defer的函数中使用。

• 嵌套无法生效。

• 只在当前goroutine生效。

• defer的语句是后进先出。 在多个defer存在的时候需要注意。

如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈。

小结：

• error尽可能提供简明的上下文信息链，方便定位问题。
• panic用于真正异常的情况。
• recover生效范围，在当前goroutine的被defer的函数生效。

---

性能优化建议

• 前提是满足正确可靠、简洁清晰等质量因素。

• 是综合评估，有时候时间效率和空间效率可能对立。

Go语言提供了支持基准性能测试的benchmark工具。

---

slice预分配内存。

• 陷阱：大内存未释放。
• 使用copy替代re-slice。

map预分配内存。

字符串拼接使用string.Builder。

• bytes.Buffer 会比string.Builder多一次内存分配。

空结构体

• 空结构体struct{}实例不占用任何的内存空间
• 可以作为占位符使用。
• 实现Set，可以考虑用map代替。

atomic包

• 锁的实现是通过操作系统实现，属于系统调用。
• atomic操作是通过硬件实现，效率比锁高。
• sync.Mutex应该用来保护一段逻辑，不仅仅用于保护单一变量。

小结

• 避免常见的性能陷阱可以保证大部分程序的性能。
• 普通应用代码，不要一味追求程序性能。
• 越高级的性能优化手段越容易出现问题。
• 在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能。