编程规范
编程原则
实际应用场景干变万化，各种语言的特性和语法各不相同，但是高质量编程遵循的原则是相通的。
简单性
- 消除“多余的复杂性”，以简单清晰的逻辑编写代码
- 不理解的代码无法修复改进
可读性
- 代码是写给人看的，而不是机器
- 编写可维护代码的第一步是确保代码可读
生产力
- 团队整体工作效率非常重要
代码格式
可以使用gofmt格式化代码，自动可视化Go语言为官方统一风格。
注释
-
注释应该解释代码如何做的
-
注释应该解释代码实现的原因
-
注释应该解释代码什么情况会出错
命名规范
变量
- 简洁胜于冗长
- 缩略词全大写，但当其位于变量开头且不需要导出时，使用全小写
-
- 例如使用 ServeHTTP 而不是 ServeHttp
-
- 使用 XMLHTTPRequest 或者 xmIHTTPRequest
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息
-
- 全局变量在其名字中需要更多的上下文信息，使得在不同地方可以轻易辨认出其含义
函数
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的
- 函数名尽量简短
- 当名为 foo 的包某个函数返回类型 Foo 时，可以省略类型信息而不导致歧义
- 当名为 foo 的包某个函数返回类型 T时 (T 并不是 Foo)，可以在函数名中加入类型信息
包
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如 schema、task 等
- 不要与标准库同名。例如不要使用 sync 或者 strings
以下规则尽量满足，以标准库包名为例
- 不使用常用变量名作为包名。例如使用 bufio 而不是 buf
- 使用单数而不是复数。例如使用 encoding 而不是 encodings
- 谨慎地使用缩写。例如使用 fmt 在不破坏上下文的情况下比 format 更加简短
参考资料
Google推出的Go语言编码规范
包含Style Guide，Style Decisions和Best Practices
- Style Guide是Go编码规范的基础，这里描述的规则是通用的，所有Go开发者都必须遵守。Style Decisions和Best Practices都遵循了Style Guide里的规则。
- Style Decisions讲述了部分具体的编码规范以及背后的原因。这里的内容会随着新的语言特性、新的库或者新的编程模式而发生变化。
- Best Practices讲述了具体写代码过程中的最佳实践。参考这个最佳实践，可以让代码的可读性更好、代码更健壮，有利于代码的可持续维护。
| Document | Link | Primary Audience | Normative[2] | Canonical[3] |
|---|---|---|---|---|
| Style Guide | google.github.io/styleguide/… | Everyone | Yes | Yes |
| Style Decisions | google.github.io/styleguide/… | Readability Mentors | Yes | No |
| Best Practices | google.github.io/styleguide/… | Anyone interested | No | No |
性能优化
- 尽可能在初始化时提供容量信息
- 及时释放大内存
- 可以使用copy代替re-slice
- 字符串拼接使用+性能最差，string.Builder可以预先申请一段字符串空间，在拼接等操作时就不需要再分配
- 空结构体不占内存空间，可作为占位符使用
- 实现set时可以考虑用map代替
