这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
本次笔记将记录编程的规范（高质量编程）
编程的规范
代码格式
gofmt，以及goimports自动格式化代码二者都可
在IDEA中，格式化代码的快捷键为Ctrl+Alt+L
注释
注释的作用：
- 解释代码的作用
- 解释代码如何做的
- 解释代码实现原因
- 解释代码错误可能原因
- 注释公共符号
解释代码的作用
解释代码如何做的
解释代码实现原因
解释代码错误可能原因
注释公共符号
开发者定义的各种符号，如ERROR、EOF等等，都需要注释其代码意义
Good code has lots of comments, bad code requires lots of comments
好的代码有很多注释，坏代码需要很多注释
-----------Dave Thomas and Andrew Hunt
命名规范
- 尽量简洁
- 缩略词全大写，特殊情况全小写
- 越远则需要携带越多的上下文信息
- 全局变量在其名字中需要更多的上下文信息
简洁
缩略词
携带越多的信息
package
只由小写字母组成。不包含大写字母和下划线
短并包含一定的上下文信息。例如schema、task 等
不与标准库同名。
控制流程
- 避免嵌套
- 尽量保持代码路径为最小缩进
避免嵌套
从最简单的if else 开始，如果两个分支都包含return语句，则可以去除冗余的else方便后续维护，else一般是正常的流程，如果在流程中还有新的判断逻辑，应该新增if判断，避免分支嵌套
尽量保持代码路径为最小缩进
优先处理特殊、错误情况，尽早返回或继续循环来避免嵌套
函数最后一行返回错误，必须追溯到最早匹配的左括号，才能了解何时会触发错误，如果中间的代码很长，这必然会增加阅读的成本和理解的成本。如果后续流程新增了新的判断逻辑或新的函数调用，则又是一层嵌套，代码可读性的降低是指数级变化的。
相比之前的代码，满足了优先处理错误情况的原则，可读性有了极大的提高。
· 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
· 正常的流程应沿着屏幕向下移动
· 提升代码的可读性和可维护性
· 故障问题一般出现在复杂的条件或循环语句中
错误和异常处理
因为错误和异常是不正常的情况，除了希望程序能兼容这些场景外，重要的也有记录问题的上下文信息，方便后续定位原因 在明确panic recover这些功能的作用范围的情况下，编写更可靠的程序
- error尽可能提供简明的上下文信息链，方便定位问题
- panic用于真正异常的情况
- recover生效范围应当在当前goroutine的被defer的函数之中
