高质量：
代码正确可靠、简洁清晰的目标；
- 各种边界条件是否考虑完备
- 异常情况处理,稳定性保证
- 易读易维护
编程原则：
1.简单性：
- 消除“多余的复杂性”,以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进
2.可读性:
- 代码是写给人看的,而不是机器
- 编写可维护代码的第一步是确保代码可读
3.生产力:
- 团队整体工作效率非常重要
编码规范：
包含：代码格式、注释、命名规范、控制流程、错误和异常处理等；
1.代码格式：
推荐使用gofmt自动格式化代码：
gofmt是 Go 语言官方提供的代码格式化工具。它会按照 Go 语言的标准风格自动对代码进行格式化，包括缩进、空格、括号位置、换行等诸多方面，确保代码风格的一致性。- 这种一致性对于团队合作非常重要，因为不同的开发者可能有不同的代码书写习惯，而
gofmt可以统一这些风格，让代码更易于阅读和维护。
2.注释：好的代码有很多注释，坏的代码需要更多的注释
公共符号始终要注释；
- 包中声明的每个公共的符号:变量、常量、函数以及结构都需要添加注释
- 任何既不明显也不简短的公共功能必须予以注释
- 无论长度或复杂程度如何,对库中的任何函数都必须进行注释
注释应该解释代码如何做的；代码实现的原因；解释代码什么情况会出错；
3.命名规范:
-
简洁胜于冗长
-
缩略词全大写,但当其位于变量开头且不需要导出时,使用全小写
- 例如使用ServeHTTP 而不是 ServeHttp
- 使用XMLHTTPRequest 或者 xmlHTTPRequest
-
变量距离其被使用的地方越远,则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息,使得在不同地方可以轻易辨认出其含义
-
函数和方法命名:
- 函数和方法名也采用驼峰命名法。函数名应该清晰地表达函数的功能。例如，
CalculateSum、PrintReport等。 - 如果是方法，接收者（
receiver）变量名的第一个字母应该是小写（通常使用一个或两个字母来表示接收者类型），比如func (p *Person) GetName()中p是Person类型的接收者。
- 函数和方法名也采用驼峰命名法。函数名应该清晰地表达函数的功能。例如，
-
包命名
- 包名应该是小写字母组成的单词，不使用下划线或混合大小写。例如，
http、fmt等都是很好的包名示例。包名应该简洁且能够准确地反映包的功能。 - 避免使用与标准库包名冲突的名称，以防止命名空间混乱。
- 包名应该是小写字母组成的单词，不使用下划线或混合大小写。例如，
4.控制流程：
- 避免嵌套，保持正常流程清晰
- 尽量保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况,尽早返回或继续循环来减少嵌套
5.错误和异常处理：
-
简单错误：简单的错误指的是仅出现一次的错误,且在其他地方不需要捕获该错误；优先使用errors.New 来创建匿名变量来直接表示简单错误；如果有格式化的需求,使用fmt.Errorf；
-
错误的Wrap和 Unwrap：错误的Wrap实际上是提供了一个error嵌套另一个error的能力,从而生成一个error的跟踪链；在fmt.Errorf 中使用:%w 关键字来将一个错误关联至错误链中；
-
错误判定：
- 判定一个错误是否为特定错误,使用errors.ls；
- 不同于使用 == ,使用该方法可以判定错误链上的所有错误是否含有特定的错误
- 在错误链上获取特定种类的错误,使用errors.As
-
panic
- 不建议在业务代码中使用panic
- 调用函数不包含 recover 会造成程序崩溃
- 若问题可以被屏蔽或解决,建议使用error 代替 panic
- 当程序启动阶段发生不可逆转的错误时,可以在 init或 main 函数中使用 panic
-
recover
- recover只能在被defer的函数中使用
- 嵌套无法生效
- 只在当前goroutine生效
- defer的语句是后进先出
- 如果需要更多的上下文信息,可以recover后在log中记录当前的调用栈
