高质量编程

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

各种边界条件是否考虑完备
异常情况处理，稳定性保证
易读易维护

编程原则

简单性

消除“多余的复杂性”，以简单清晰的逻辑编写代码
不理解的代码无法修复改进
可读性
代码是写给人看的，而不是机器
编写可维护代码的第一步是确保代码可读
生产力
团队整体工作效率非常重要

编写规范

注释

公共符号始终要注释

包中声明的每个公共的符号：变量、常量、函数以及结构都需要添加注释
任何既不明显也不简短的公共功能必须予以注释
无论长度或复杂程度如何对库中的任何函数都必须进行注释

注释应该做的：

注释应该解释代码作用
注释应该解释代码如何做的
注释应该解释代码实现的原因
注释应该解释代码什么情况会出错

命名规范

变量名

简洁胜于冗长
缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
- 例如使用 ServeHTTP 而不是 ServeHttp
- 使用 XMLHTTPRequest 或者 xmlHTTPRequest
变量距离其被使用的地方越远，则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义

例如：

// Bad
for index := 0; index < len(s); index++{
	//do something...
}

// Good
for i := 0; i < len(s); i++{
	//do something...
}

i 和 index 的作用域范围仅限于 for 循环内部时，index 的额外冗长几乎没有增加对程序的理解

// Good
func (c *Client) send(req *Request, deadline time.Time)

// Bad
func (c *Client) send(req *Request, t time.Time)

将 deadline 替换成t 降低了变量名的信息量，t 常代指任意时间
deadline 指截止时间，有特定的含义

函数名

函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
函数名尽量简短
当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
当名为 foo 的包某个函数返回类型 T时(T 并不是 Foo)，可以在函数名中加入类型信息

例如：
在 http 包中创建服务器的函数

// Good
func Server(I net.Listener, handler Handler) error

// Bad
func ServerHTTP(I net.Listener, handler Handler) error

因为我们是在 http 包下创建的函数，如果其他包中调用这个函数那么是 http.函数名，http就没必要出现在函数名中了

package

只由小写字母组成。不包含大写字母和下划线等字符
简短并包含一定的上下文信息。例如 schema、task 等
不要与标准库同名。例如不要使用 sync 或者 strings

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

不使用常用变量名作为包名。例如使用 bufio 而不是 buf
使用单数而不是复数。例如使用 encoding 而不是 encodings
谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format 更加简短

控制流程

避免嵌套，保持正常流程清晰

// Bad
if foo {
	return x
}else {
	return nil
}

// Good
if foo {
	return x
}
return nil

如果两个分支中都包含return语句，则可以去除冗余的else

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

优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套

// Bad
func OneFunc() err {
	err := doSomething()
	if err == nil {
		err := doSomething()
		if err == nil{
			return nil // normal case
		}
		return err
	}
	return err
}

// Good
func OneFunc() err {
	if err := doSomething(); err != nil {
		return err
	}
	if err := doSomething(); err != nil {
		return err
	}
	return nil // normal case
}

最常见的正常流程的路径被嵌套在两个 if 条件内
成功的退出条件是 return nil，必须仔细匹配大括号来发现函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误
如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套

错误和异常处理

简单错误

简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
优先使用 errors.New 来创建匿名变量来直接表示简单错误
如果有格式化的需求，使用 fmt.Errorf

错误的 Wrap 和 Unwrap

错误的 Wrap 实际上是提供了一个 error 嵌套另一个error 的能力，从而生成一个 error 的跟踪链
在 fmt.Errorf 中使用: %w 关键字来将一个错误关联至错误链中

判断错误

判定一个错误是否为特定错误，使用 errors.ls

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

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

panic

注意在Go语言中，recover只在defer调用的函数中有效，并且defer要在panic之前先注册，否则不能捕获异常
panic相当于直接 throw 一个异常来终止程序运行，当panic被捕获到后，被注册的函数将获得程序控制权

不建议在业务代码中使用 panic
调用函数不包含 recover 会造成程序崩溃
若问题可以被屏蔽或解决，建议使用error 代替 panic
当程序启动阶段发生不可逆转的错误时可以在 init 或 main 函数中使用 panic

recover

recover 只能在被 defer 的函数中使用
嵌套无法生效
只在当前 goroutine 生效
defer 的语句是后进先出

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

优化性能

性能优化的前提是满足正确可靠、简洁清晰等质量因素
性能优化是综合评估，有时候时间效率和空间效率可能对立
针对 Go 语言特性，介绍 Go 相关的性能优化建议

Benchmark

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

go test -bench=. -benchmem

Slice 预分配内存

// Bad
func NoPreAlloc(size int) {
	data := make([]int, 0)
	for k := 0; k < size; k++ {
		data = append(data, k)
	}
}

// Good
func NoPreAlloc(size int) {
	data := make([]int, 0, size)
	for k := 0; k < size; k++ {
		data = append(data, k)
	}
}

切片本质是一个数组片段的描述
- 包括数组指针
- 片段的长度
- 片段的容量(不改变内存分配情况下的最大长度)
切片操作并不复制切片指向的元素
创建一个新的切片会复用原来切片的底层数组

在已有切片基础上创建切片，不会创建新的底层数组场景
- 原切片较大，代码在原切片基础上新建小切片
- 原底层数组在内存中有引用，得不到释放
可使用 copy 替代 re-slice
map 也是一样，不断向 map 中添加元素的操作会触发 map 的扩容，提前分配好空间可以减少内存拷贝和 Rehash 的消耗

字符串处理

常见的字符串拼接方法：strings.Builder

// Bad
func Plus(n int, str string) string {
	s := ""
	for i := 0; i < n; i++ {
		s += str
	}
	return s
}

// Good
func Plus(n int, str string) string {
	var builder strings.Builder
	for i := 0; i < n; i++ {
		builder.WriteString(str)
	}
	return builder.String()
}

使用 strings.Builder

使用+拼接性能最差，strings.Builder，bytes.Buffer 相近，strings.Buffer 更快

分析

字符串在 Go 语言中是不可变类型，占用内存大小是固定的
使用 +每次都会重新分配内存
strings.Builder，bytes.Buffer 底层都是 []byte 数组
内存扩容策略,不需要每次拼接重新分配内存

代码优化