这是我参与「第五届青训营 」笔记创作活动的第3天
1 高质量编程
代码正确可靠 简洁清晰
边界条件是否完备 异常处理 稳定型保证 易读易维护
原则
简单性 可读性 生产力
代码格式 注释 命名规范 控制流程 错误和异常处理
1.2.2-注释 公共符号始终要注释 不需要注释实现接口的方法
推荐使用gofmt自动格式化代码
gofmt goimports 自动增删依赖包
作用 适合注释公共符号 描述功能用途 如何做 适合注释实现过程 实现原因 解释代码外部因素 提供额外上下文 什么原因会出错 解释代码限制条件
1.2.3-命名规范 variable
简洁 缩略词全大写 位于变量开头且不需要导出时使用全小写 被使用越远 携带上下文信息越多
function 函数名不携带包名上下文信息 函数名尽量简短 包foo与函数返回类型Foo相同时可省略类型信息而不导致歧义 包foo返回类型T时 可在函数名中加入类型信息
-packge 只由小写字母组成 不包含大写下划线等 简短并包含一定上下文信息 不于标准库同名
尽量满足 不使用常规变量名作包名 用单数 谨慎使用缩写
小结 降低阅读理解成本 考虑上下文信息，设计简洁清晞名称
1.2.4-控制流程
避免嵌套 保持正常流程清晰
尽量保持正常代码路径为最小缩进
优先处理错误/特殊情况 尽早返回或继续循环减少嵌套
小结 线性原理 逻辑走直线 正常代码流程沿屏幕向下移动 提升可维护可读性 故障大多出在复杂条件语句 循环中
1.2.3-错误异常处理
简单错误 仅出现一次 优先使用errors.New 创建匿名变量直接表示简单错误 格式化fmt.Errorf、
Wrap 和Unwrap fmt.Errorf用%w关键字将一个错误关联至错误链中
错误判定 是否为特定错误errors.is 获取特定种类错误 errors.As
panic 不建议在业务代码中使用 调用函数中不包含recover会造成程序崩溃 若问题可以被屏蔽或解决 建议用error代替panic 启动阶段不可逆转错误可在init或main中使用panic
recover 只能在被defer的函数中使用 嵌套无法生效 只在当前goroutine生效 defer语句先进后出 需要更多上下文信息 可在recover后在log中记录当前调用栈
小结 error方便定位 panic真正异常 recover生效范围
1.2 编码规范
1.3性能优化建议
2 性能调优实战
