一.高质量编程
1.1 高质量编程简介
- 编写的代码能够达到正确可靠、简洁清晰的目标可称之为高质量代码
- 各种边界条件是否考虑完备
- 异常情况处理，保证稳定性
- 易读且易维护
1.2 编程原则
1.2.1 简单性
- 消除“多余复杂性”，也就是少写废话以及不必要的代码，以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进
1.2.2 可读性
- 代码是写给人看的，而不是机器，因此需要把代码写得让人看的明白
- 编写可维护代码的第一步就是确保代码可读
1.2.3 生产力
团队整体工作效率非常重要，因此需要简单可读的代码，否则会大大降低团队的效率 二.编码规范
2.1 注释
2.1.1公共符号始终要注释
- 包中声明的每个公共的符号比如变量、常量、函数、结构都需要添加注释
- 任何既不明显也不简短的公共功能必须要添加注释
- 无论长度或者复杂程度如何，对库中的任何函数都必须进行注释
2.1.2 注释应该做的
- 注释应该解释代码作用
- 注释应该解释代码如何做的（也就是写代码的思路）
- 注释应该解释代码实现的原因（也就是代码的运作情况）
- 注释应该解释代码什么情况会出错
2.2 代码格式
可以使用gofmt（官方提供的工具）来自动格式化代码，也可以使用goimports
2.3命名规范
2.3.1 变量
- 简洁优于冗长，避免又长又臭的变量名称
- 缩略词全大写，比如
ServeHTTP而不是ServeHttp，但当其位于变量开头且不需要导出时，使用全小写，比如使用XMLHTTPRequest而或者xmlHTTPRequest - 变量距离其被使用的地方越远，则需要携带越多的上下文信息，注意全局变量在其名字中需要更多上下文的信息，使得在不同地方可以轻易辨认出他的含义
2.3.2 函数
- 函数名不懈怠包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为
foo的包某个函数返回类型Foo时，可以省略类型信息而不导致歧义 - 当名为
foo的包某个函数返回类型T时（T并不是Foo），可以在函数名中加入类型信息
2.3.3 package（包）
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如
schema、task等 - 不要与标准库同名。例如不要使用
sync或者strings
以下规则尽量满足，以标准库包名为例
- 不使用常用变量名作为包名。例如使用
bufio而不是buf - 使用单数而不是复数。例如使用
encoding而不是encodings - 谨慎地使用缩写。例如使用
fmt在不破坏上下文的情况下比format更加简短
