1.编程原则
1. 简单性：以清晰的逻辑写代码
2. 可读性：编写可维护的代码第一步是保证代码可读
3. 生产力：保证团队的工作效率
工具介绍：gofmt
在goland中配置gofmt
点击设置->工具->file watcher，点击加号，然后在参数中添加-l -w -s参数，添加配置保存源码时，goland就会执行代码格式化了
2. 编码规范-注释
3. 注释应该做的
·解释代码作用
·解释代码怎么运行
·解释代码实现效果的原理
·解释代码在什么时候会出错
·包中声明的每个公共的符号都需要添加注释
·任何既不明显也不简短的公共功能也要注释
·对库中的任何函数都要注释
·注释应该提供代码未表达出的上下文信息
4. 编码规范-命名规范
简洁胜于冗长
缩略词必须全大写，当其位于变量开头且不要导出时，用全小写
变量距离其被使用的地方越远则需要携带越多上下文信息
如果一个变量仅被创建用于一个简单的用途，那么这个变量应该越简单越好
比如一个for循环里的循环变量i
将变量名换成某些特定的单词会增加代码中信息的容量
函数名的命名规范：
函数名不携带包名的上下文信息，因为两者总是成对出现
函数名尽量短
package的命名规范
只有小写字母构成，不包含大写字母和下划线字母
简短并包含一定的上下文信息
不要与标准库同名，例如不要用strings
不使用常用变量名作为包名以免导致歧义
使用单数而不是复数，例如使用encoding而不是使用encodings
谨慎使用缩写，例如fmt在不破环上下文的情况下比format更简短
5. 编码规范-控制流程
避免嵌套，保证流程清晰
例如if else语句中都包含了return，则可以把去掉else把else的return语句放在if外面这样就能省去一次判断
优先处理错误，尽量避免返回或者继续循环
处理逻辑尽量走直线，避免复杂的嵌套分支
正常流程代码沿着屏幕向下移动
提升代码的可维护性和可读性
故障大多出在复杂的条件语句或者循环语句中
6. 编码规范-错误异常和错误处理
错误的类型：
简单错误
Panic
用panic(err)来使程序报出异常
错误的warp和unwarp
Warp提供了错误套错误的能力，可以实现一个error跟踪链来追寻到错误的最终原因
Fmt.Errorf()返回错误并且在控制台输出，你可以在里面添加任何用于占位的字符，并且可以使用格式化输出，注意用%w来格式化输出你的错误
用%w关键字来将一个错误关联至错误链中
errors.Is()来判断一个错误是否为特定错误
errors.Is(err1,err2)用于判断err1是否与err2是同类的错误err是被判断的错误，err2是目标错误
Errors.As(err1,&err)同样用于判断err1是否和err是同类型的错误，不同在于第二个参数是我们需要判断的错误的指针类型所以要在判断的错误前面加上取址符来转成指针
Panic，当程序在启动阶段出现不可逆的错误时，可以在init或者main函数中使用panic
Error和panic类比于java中的exception和error？
若问题可以被解决建议用error代替panic
Recover
通常写法：
defer func() {
if err := recover(); err !=nil {
fmt.Println(err)
}
}()
程序用recover来捕获异常，是程序即使出现了panic仍然可以继续运行defer然后中断后续的执行
