编码规范——命名规范
package 只有小写字母组成，不包含大写字母和下划线等字符 简短并包含一定的上下文信息 不要与标准库同名 以下规则尽量满足，以标准库为例 不使用常用变量名作为包名，例如使用bufio而不是buf 使用单数而不是复数 谨慎地使用缩写，例如使用fmt在不破坏上下文的情况下比format更加简短 小结： 核心目标是降低阅读理解代码的成本 重点考虑上下文信息，设计简洁清晰地名称 编码规范——控制流程 避免嵌套，保持正常流程清晰 如果两个分支中都包含return语句，则可以去除冗余地else 尽量保持正常代码路径为最小缩进 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套 从上到下是一个正确的进行过程 小结： 线性原理，处理逻辑尽量走直线，避免复杂地嵌套分支 正常流程代码沿着屏幕向下移动 提升代码可维护性和可读性 故障问题大多出现在复杂地条件语句和循环语句中 编码规范——错误和异常处理 简单错误 简单的错误指的是仅出现一次的错误，且在其他地方不需要捕获该错误 优先使用errors.New来创建匿名变量来直接表示简单错误 如果有格式化地需求，使用fmt.Errorf 错误的Wrap和Unwrap 错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error的跟踪链 在fmt.Errorf中使用：%w关键字来将一个错误关联至错误链中 错误判定 判定一个错误是否为特定错误，使用errors.ls 不同于使用==，使用该方法可以判定错误链上的所有错误是否含有特定的错误 在错误链上获取特定种类的错误
总结3：
注释编码规范：1、所有导出对象都需要注释说明其用途；非导出对象根据情况进行注释。2、如果对象可数且无明确指定数量的情况下，一律使用单数形式和一般进行时描述；否则使用复数形式。3、包、函数、方法和类型的注释说明都是一个完整的句子。4、句子类型的注释首字母均需大写；短语类型的注释首字母需小写。5、注释的单行长度不能超过80个字符。
- 当某个部分等待完成时，可用
TODO:开头的注释来提醒维护人员。 - 当某个部分存在已知问题进行需要修复或改进时，可用
FIXME:开头的注释来提醒维护人员。 - 当需要特别说明某个问题时，可用
NOTE:开头的注释。
