Go语言编码规范｜青训营笔记

Go语言编码规范｜青训营笔记

前言

​

编码规范

注释

注释应该解释代码作用

注释应该解释代码如何做的

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

解释代码什么情况下会出错公共符号始终要注释（公共变量、常量、函数、结构）

命名规范

变量

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

函数

函数名不携带包名的上下文信息，因为函数名和包名总是成对出现函数名尽量简短当名为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性能调优实战》，关于实际业务开发中的优化则需要后续结合实际生产情况进一步深入探究。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。