写在前面
这几天总是焦虑又不安，今天就来回顾一下课程中所学的一些提升编程质量、调优性能的方法，希望可以借此慢慢平复内心跌宕起伏的心情。
高质量编程标准
- 正确可靠，简洁清晰
- 各种边界条件是否完备
- 异常情况处理，稳定性保证
- 易读易维护
公共符号始终要注释
- 包中声明地每个公共的符号，包括变量、常量、函数以及结构都需要添加注释
- 任何既不明显也不简短的公共功能必须予以注释
- 无论长度或复杂度如何，对库中的任何函数都必须进行注释
推荐使用gofmt自动格式化代码，或者goimports
注释应该如何做
- 注释应该解释代码作用
- 注释应该解释代码如何是做的
- 注释应该解释代码实现的原因
- 注释应该解释代码可能在什么情况会出错
自变量命名规范
- 简洁胜于冗长
- 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写：
例如使用ServeHTTP 而不是ServeHttp 使用XMLHTTPRequest 或者 xmlHTTPRequest - 变量距离被使用的地方越远，则需要携带越多的上下文信息
例如全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易 辨认出其含义
函数名命名规范
- 函数名不携带包名的上下文信息，因为包名与函数名总是成对出现
- 函数名尽量简短
- 当名为foo的包某个返回类型foo时，可以省略类型信息而不导致歧义
- 当名为foo的包某个函数返回类型T时（T并不是foo），可以在函数名中加入类型信息
package命名规范
- 只由小写字母组成，不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息，例如schema,task等
- 不要与标准库同名，例如不要使用sync或者strings
- 不使用常用变量名作为包名。例如使用bufio而不是buf
- 使用单数而不是复数。例如使用encoding而不是encodings
- 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短
控制流程规范
- 避免嵌套，保持正常流程清晰
- 尽量保持正常代码路径为最小缩进
- 优先处理错误情况/特殊情况，尽早返回或继续循环来减少嵌套
小结
- 线性原理，处理逻辑尽量走直线，避免复杂的嵌套分支
- 正常流程代码沿着屏幕向下移动
- 提升代码可维护性和可读性
- 故障问题大多出现在复杂的条件语句和循环语句中
