这是我参与【第五届青训营】伴学笔记创作活动的第3天

高质量编程

正确可靠、简洁清洗
各种边界条件是否考虑完备
异常情况处理，稳定性保证
易读，易维护

1.编程原则

简单性：消除“多余的复杂性”，以简单清晰的逻辑编写代码：不理解的代码无法修复改进
可读性：代码是写给人看的，而不是机器；编写可维护代码的第一步是确保代码可读
生产力：团队整体工作效率非常重要

2.编码规范

（1）注释：公共符号始终要注释（例外：不需要注释接口的方法）
    1）包中声明的每个公共符号：变量、常量、函数及结构
    2）任何既不明显也不简短的公共功能
    3）无论长度或复杂程度如何，库中任何函数
    **注释应该注释代码作用 适合注释公共符号
    **注释应该解释代码如何做的  适合注释实现过程
    **注释应该解释代码实现的原因  适合解释外部因素，提供额外上下文
    **注释应该解释代码什么情况会出错  适合解释代码限制条件
（2）代码格式：自动格式化代码
    gofmt;goimport(gofmt+依赖包管理)
（3）命名规范：
    1）变量variable
        简洁胜于冗长；缩略词全大写，但当其位于变量开头且不需要导时，使用全小写；变量距离其被使用的地方越远；则需要携带越多的上下文信息
    2）函数function
        函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
        函数名尽量简短
        当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义
        当名为foo的包某个函数返回类型T时（不是Foo），可以在函数名中加入类型信息
    3）包package
        只由小写字母组成。不包含大写字母和下划线等字符
        简短并包含一定上下文信息。例如：schema,task等
        不要与标准库同名，例如不要使用sync或strings
            **以下规则尽量满足，以标准库包名为例
                不使用常用变量名作为包名
                使用单数而不是复数
                谨慎地使用缩写
（4）控制流程
    避免嵌套，保持正常流程清晰
    尽量保持正常代码路径为最小缩进
（5）错误和异常处理
    1）错误
        简单错误
            仅出现一次的错误，且在其他地方不需捕获该错误
            优先使用errors.New来创建匿名变量来直接表示简单错误
            如果有格式化的需求，使用fmt.Errorf
        复杂错误
        错误的Wrap和Unwrap
            错误的Wrap实际上是提供了一个error嵌套另一个error的能力，从而生成一个error跟踪链
            在fmt.Errorf中使用%w关键字来将一个错误关联至错误链中
        错误判定
            判定一个错误是否为特定错误，使用errors.Is
            在错误链上获取特定种类的错误，使用Errors.As
        异常panic
            不建议在业务代码中使用panic
            调用函数不包含recover会造成程序崩溃
            若问题可以被屏蔽或解决，建议使用error代替panic
            当程序启动阶段发生不可逆转错误时，可以在init或main函数中使用panic
        recover
            recover只能在被defer的函数中使用
            嵌套无法生效
            只在当前goroutine生效
            defer的语句是先进后出
            将panic上下文记录，如果需要更多上下文信息可以recover后再Log中记录当前调用栈