这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记
一、编码规范-代码格式
1.推荐使用gofmt自动格式化代码
二、注释
1.注释应该解释代码作用
2.注释应该解释代码如何做的
3.注释应该解释代码实现的原因
4.注释应该解释代码什么情况会出错
5.公共符号始终要注释（但是不需要注释实现接口的方法。） 小结：代码是最好的注释，注释应该提供代码未表达出的上下文信息
三、命名规范—变量命名
1.简介胜于冗长
2.缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写 例：使用ServeHTTP而不是ServeHttp 例：使用XMLHTTPRequest或者xmlHTTPRequest
3.变量距离其被使用的地方越远，则需要携带越多的上下文信息 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出变量含义
四、命名规范—函数命名
1.函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
2.函数名尽量简短
3.当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
4.当名为foo的某个函数返回类型T时，可以在函数中加入类型信息
五、命名规范—包的命名
1.只由小写字母组成，不包含大写字母和下划线等字符
2.简短并包含一定的上下文信息。例如 schema 、 task 等 六、命名方式哪种更好 package time func Now() Time //or func NowTime() Time 两种表达方式第一种更简洁清晰，第一种更好。
3.不要与标准库同名。例如不要使用 sync 或者 strings
4.不使用常用变量名作为包名。例如使用 bufio 而不是 buf
5.使用单数而不是复数。例如使用 encoding 而不是 encodings
6.谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format更加简短
五、编码规范—控制流程
1.避免嵌套，保持正常流程清晰
2.尽量保持正常路径为最小缩进
3.处理逻辑尽量走直线
4.提升代码可读性和维护性
5.故障大多出现在复杂的条件语句中
六、错误异常处理
1.简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
2.优先使用errors。New来创建匿名变量来直接表示简单错误
3.错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个err错误
4.判定一个错误是否为特定错误，使用errors.As
5.不建议在业务代码中使用panic。若问题可以屏蔽和解决，建议使用error
6.recover只能在被defer的函数中使用，嵌套无法生效。
七、性能优化原则
1.要依靠数据而不是猜测
2.要定位最大瓶颈而不是细枝末节
3.不要过早优化
4.不要过度优化
作者：学弟呦
链接：juejin.cn/post/710873…
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
