前言
编码规范
注释
- 注释应该解释代码作用
- 注释应该解释代码如何做的
- 注释应该解释代码实现的原因
- 解释代码什么情况下会出错
- 公共符号始终要注释（公共变量、常量、函数、结构）
命名规范
- 变量
- 简洁
- 缩略词全大写，但当其位于变量开头且不需要导出时，缩略词全小写
- 变量距离起被使用地方越远，则需要携带更多上下文信息
- 全局变量在其名字中需要更多上下文信息，是的其在不同地方可以轻易辨认出含义
- 函数
- 函数名不携带包名的上下文信息，因为函数名和包名总是成对出现
- 函数名尽量简短
- 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
- 当名为foo的包某个函数返回类型为T（T不是Foo），可以在函数名中加入类型信息
- 包
- 只有小写字母组成，没有大写字母和下划线
- 简短且包含一定上下文信息，如task、schema
- 不要与标准库同名
控制流程
- 避免嵌套，保证正常流程清晰
- 如果两个分支都包含return，则可以去除冗余else
- 尽量保证正常代码路径为最小缩进，优先处理错误/特殊情况，并且尽早返回或者继续循环来减少嵌套，增加可读性
错误和异常
- 简单错误处理：优先使用errors.New来创建匿名变量来直接表示该错误，有格式化需求使用fmt.Errorf
- 错误的Wrap和Unwrap：在fmt.Errorf中使用%w关键字来将一个错误wrap至其错误链中
- 错误判定
- 使用errors.Is可以判定错误链上的所有错误是否含有指定错误
- 在错误链上获取指定种类的错误，errors.As
- panic
- 不建议在业务代码中使用panic
- 如果当前goroutine中所有的deferred函数都不包含recover整个程序会崩溃
- 启动阶段发生不可逆转错误时，可以在init或者main函数中使用panic
- recover
- recover只能在被defer的函数中使用，嵌套无法生效，只在当前goroutine生效
- 如果需要更多上下文信息，可以recover后在log中记录当前的调用栈
性能优化建议
- 在满足正确性、可靠性、健壮性、可读性的前提下，设法提高程序的效率
- 性能对比测试代码，可参考：github.com/RaymondCode…
slice预分配内存
- 尽可能在使用
make()初始化切片的时候提供容量信息，因为切片有三个属性：指针ptr、长度len、容量cap，ptr会指向一个底层数组，给切片append一个元素之后，如果len小于等于cap，则不会触发扩容机制导致发生内存拷贝，如果len大于cap，则会分配一块更大的内存容纳新的数组 - 另一个陷阱：大内存得不到释放，在已有的切片基础上进行切片，其底层数组依赖原来的切片，那么如果原切片很大，而依赖它的新切片只需要少量数组中的元素，则依旧会让底层数组由于有元素被占用而整体得不到释放，这里推荐使用
copy函数（开辟新空间去存放拷贝的数组值）
map预分配
- 不断向map中添加元素会触发map的扩容
- 根据实际需求提前预估好需要的空间，从而减少内存拷贝和
Rehash的消耗
使用strings.Builder
- 字符串拼接：
strings.Builder优于bytes.Buffer优于+运算符 - Go字符串是不可变类型，使用+拼接两个字符串时，生成一个新字符串需要开辟新的空间存放，新空间大小是原来两个字符串之和
-
strings.Builder和bytes.Buffer的内存是以倍数申请的 -
strings.Builder和bytes.Buffer底层都是[]byte数组，bytes.Buffer转化为字符串时重新申请了一块空间存放生成的字符串变量，而strings.Builder直接将底层的[]byte转换成字符串类型返回
使用空结构体节省内存
- 空结构体不占内存空间，可以作为占位符使用
- Go语言标准库没有
Set实现，可以使用map代替。对于集合场景，只要使用map的key而不需要值
使用atomic包
- 锁是通过操作系统实现的。属于系统调用，
atomic操作是通过硬件实现的，效率比锁高很多 -
sync.Mutex应该用于保护一段逻辑，不仅仅用于保护一个变量 - 对于非数值系列，可以使用
atomic.Value，atomic.Value能承载一个interface{}
结束语
这篇文章罗列了Go的编码规范，以及一些提高运行效率的编码技巧。关于性能调优部分请参看另一篇笔记《pprof性能调优实战》，关于实际业务开发中的优化则需要后续结合实际生产情况进一步深入探究。
关注微信公众号【程序员白泽】，将同步字节青训营期间的作业笔记。
