这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记
本节课重点学习了高质量编程的要点，以下是我分享的内容。
高质量代码：编写的代码能够达到正确可靠、简洁清晰的目标
- 各种边界条件是否考虑完备
- 异常情况处理，稳定性保证
- 易读易维护 编程原则：
简单性
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进 可读性：
- 代码是写给人看的，而不是机器
- 编写可维护代码的第一步是确保代码可读 生产力
- 团队整体工作效率非常重要 编码规范
代码格式----推荐使用gofmt自动格式化代码
注释：
解释代码作用（适合注释公共代码）、解释代码如何做的（适合注释实现过程）、解释代码实现的原因（注释代码的外部因素、提供额外上下文）、解释代码什么情况会出错（适合解释代码的限制条件）。
**代码是最好的注释；注释应该提供代码末表达出的上下文信息。 **
命名规范：
variable
-
简洁胜于冗长
-
缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写。
- 例如使用ServeHTTP而不是ServeHttp - 使用XMLHTTPRequest或者xmlHTTPRequest -
变量距离其被使用的地方越来越远，则需要携带越多的下文信息
- 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义function
-
函数名不携带包含名的上下文信息，因为包名和函数总是成对出现的
-
函数名尽量简短
-
当名为foo的包某个函数返回类型foo时，可以省略类型信息而不导致歧义
-
当名为foo的包某个函数返回类型T时（T并不是foo），可以在函数名中加入类型信息
package
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如schema、task等
- 不要与标椎库同名。例如不要使用sync或者strings
以下规则尽量满足，以标椎库包名为例
- 不使用常用变量名作为包名。例如使用butfio而不是buf
- 使用单数而不是复数。例如使用encoding而不是encodings
- 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短
小结
-
核心目标是降低阅读理解代码的成本
-
重点考虑上下文信息,设计简洁清晰的名称 控制流程
-
避免嵌套,保持正常流程清晰
-
尽量保持代码正常代码路径为最小缩进
- 优先处理错误情况/特殊情况,尽早返回或继续循坏来减少嵌套 -- 最常见的正常流程的路径被嵌套在两个if条件内 --成功的退出条件是return nil，必须仔细匹配大括号来发现 --函数最后一行返回一个错误，需要追溯到匹配的左括号，才能了解何时会触发错误 --如果后续正常流程需要增加一步操作，调用新的函数，则又会增加一层嵌套 -
尽量保持正常代码路径为最小缩进
小结
- 线成性原理，处理逻辑尽量走直线，避免复杂的嵌套分布
- 正常流程代码沿着屏幕向下移动
- 提升代码课维护性和可读性
- 故障问题大多出现在复杂的条件语句和循坏语句中 错误和异常处理
简单错误
- 简单错误是指仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用errors。NEW来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用fmtErrorf
错误的Wrap和Unwrap
- 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链
- 在fmt。Error中使用：%w关键字来讲一个错误关联至错误链中
错误判定
- 判定一个错误是否为特定错误，使用errors.ls
- 不同于使用==，使用该方法可以判定错误链上的所有信息是否含有特定的错误
- 在错误链上获取特定种类的错误，使用errors.AS
panic
- 不建议在业务代码中使用panic
- 调用函数不包含recover会造成程序崩溃
- 若问题可以屏蔽或解决，建议使用error代替panic
- 当程序启动阶段发生不可逆转的错误是，可以在init或main函数中使用panic
recover
- recover只能在被defer的函数中使用
- 嵌套无法生效
- 只在当前goroutine生效
- defer的语句是后进先出
- 如果需要更多的上下文信息，可以recover后在log中记录的调用栈 小结
- error尽可能提供简明的上下文信息链，方便定位处理
- panic用于真正异常的情况
- recover生效范围，在当前goroutine的被defer的函数中生效
