- 高质量编程
- 高质量编程简介 ——代码 正确可靠、简洁清晰
- 正确性：
- 各种边界条件是否考虑完备
- 异常情况处理，稳定性保证
- 易读易维护
- 简洁性
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
- 前两天写了个功能，咱就是说确实写到后面自己都糊涂了，不得不换个思路重新捋
- 不理解的代码无法修复改进
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
- 可读性
- 代码是写给人看的，而不是机器
- 编写可维护代码的第一步是确保代码可读
- 生产力
- 团队整体工作效率非常重要
- 正确性：
- 编码规范
- 如何编写高质量的Go代码
- 代码格式
- gofmt自动格式化代码
- 注释
- 公共符号始终要注释 例外:不需要注释实现接口的方法
- 注释应该做的
- 解释代码作用
- 解释代码如何做的
- 解释代码实现的原因
- 适合解释代码的外部因素
- 提供额外上下文
- 解释代码什么情况会出错
- 小结
- 代码是最好的注释
- 注释应该提供代码未表达出的上下文信息
- 命名规范
- variable
- 简洁胜于冗长
- 缩略词全大写，但当其位于变量开头（go语言开头大小写的作用）且不需要导出时，使用全小写
- ServeHTTP(✔)ServeHttp(×)
- XMLHTTPRequest(✔) or xmlHTTPRequest(×)
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
- function
- 函数不携带包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
- 当名为foo的包某个函数返回类型T时（T并不是Foo）,可以在函数中加入类型信息
- package
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如schema、task等
- 不要与标准库同名。如 sync或strings
- 应尽量满足的条件：
- 不使用常用变量名作为包名
- 使用单数而不是复数
- 谨慎地使用缩写
- variable
- 控制流程
- 避免嵌套，保持正常流程清晰
- 对于相对复杂的，优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
- 尽量保持正常代码路径为最小缩进
- 小结
- 线性原理：处理逻辑尽量走直线，避免复杂的嵌套循环
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
- 错误和异常处理
- 简单错误
- 指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用errors.New 来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用fmt.Errorf
- 复杂错误 错误的Wrap 和 Unwrap
-
错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链
-
在fmt.Errorf中使用： %w关键字来将一个错误关联至错误链中
-
- 错误判定
- 判断一个错误是否为特定错误，使用errors.Is
- 不同于使用 ==，使用该方法可以判定错误链上的所有错误是否含有特定的错误
- 在错误链上获取特定种类的错误，使用errors.As
- 判断一个错误是否为特定错误，使用errors.Is
- panic
- 不建议在业务中使用panic
- 调用函数不包含recover会造成程序崩溃
- 若问题可以被屏蔽或解决，建议使用error代替panic
- 当程序启动阶段出现发生不可逆转的错误时，可以在init或main函数中使用panic
- recover机制
- recover只能在被defer的函数中使用
- 嵌套无法生效
- 只在当前goroutine生效
- defer的语句是后进先出
- 如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈
- 简单错误
- 代码格式
- 如何编写高质量的Go代码
- 高质量编程简介 ——代码 正确可靠、简洁清晰
反思
在之前的学习中，我只以实现某个功能为目标，却忽略了一些规范和错误处理。 如果能掌握优化部分的内容，我相信对于提高自己的代码水平是十分有益的。
