这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天,通过学习记录并总结部分知识点，不足之处请指正。 本章知识点有以下方面：
高质量编程
想要写出好的代码并不是一件容易的事情，它需要我们不断地对现有的代码进行反思 。如何改写这段代码才能让它变得更加优雅。优雅听起来是一个非常感性、难以量化的结果，然而这却是好的代码能够带来的最直观感受。
何为高质量编程？
编写的代码要能够表达出正确的意思，且能够简洁的表述目标方才能称为高质量代码。且代码要能够保证稳定，对于一些异常情况也能够进行处理。另外，当下一个人接手这个项目的时候，能够以极短时间阅读出意思并进行维护。这类代码方可成为高质量代码。
编码原则：
- 简单性
- 可读性
- 生产力
规范：
-
格式
使用 gofmt 自动格式化代码，保证所有的 Go 代码与官方推荐格式保持一致。提升可读性，风格一致的代码更便于维护、需要更少的学习成本、团队合作成本，同时可以降低 Review 成本
-
注释
最好的注释就是可以极精简的能够表述出上下文信息。
-
命名：核心目标就是降低阅读理解代码的成本。
- variable：简洁但是冗长；缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写；变量距离其被使用的地方越远，则需要携带越多的上下文信息。
- function：
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的；函数名尽量简短；当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义；当名为 foo 的包某个函数返回类型 T 时（T 并不是 Foo），可以在函数名中加入类型信息
- package：只由小写字母组成。不包含大写字母和下划线等字符；简短并包含一定的上下文信息。例如 schema、task 等；不要与标准库同名。例如不要使用 sync 或者 strings
-
流程
- 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支；
- 正常流程代码沿着屏幕向下移动；
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
-
错误及异常处理
-
简单错误
- 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误
- 优先使用errors.New来创建匿名变量来直接表示简单错误
- 如果有格式化的需求，使用fmt.Errorf
-
错误的 Wrap 和 Unwrap
- 错误的Wrap实际上是提供了一个error嵌套另一个crror的能力,从而生成—个crror的跟踪链
- 在fmt.Errorf中使用: %w关键字来将一个错误关联至错误链中
-
错误判定
- 判定一个错误是否为特定错误，使用errors.Is
- 不同于使用—-，使用该方法可以判定错误链上的所有错误是否含有特定的错误.
-
panic
- 不建议在业务代码中使用 panic
- 如果当前 goroutine 中所有 deferred 函数都不包含 recover 就会造成整个程序崩溃。
- 若问题可以被屏蔽或者解决，建议使用error代替panic.
- 当程序启动阶段发生不可逆转的错误时，可以在 init 或 main 函数中使用 panic
-
recover
- recover 生效范围:在当前 goroutine 的被 defer 的函数中生效
- 嵌套不可使用
- defer的语句是后进先出
- 如果需要更多的上下文信息，可以recover后在log中记录当前的调用栈
-
总结：开发过程最忌讳随意堆砌代码，每一行代码都应该按照最高的标准去设计和开发，这是我们保证工程质量的唯一方法。这个过程可能是复杂的，枯燥的，可能需要我们不断地对自己的知识体系更新优化，从而对代码进行完善与重构。
