高质量编程简介及编码规范
清晰的代码可以提高团队效率 清晰地表达出自己的思路是加分项
- 常见的优化手段
- 性能分析工具
- 工程中性能优化的原则和流程
高质量编程
个人理解：高质量代码需要满足业务需求的同时要利于团队协作
高质量编程简洁
编写的代码正确可靠、简洁清晰
边界条件考虑完备 异常处理、稳定性 易读、维护
简单性：消除多余的复杂性 可读性：大部分是对已有功能的扩展，编写可维护代码的第一步是保证可读 生产力：团队整体工作效率非常重要
编码规范
注释：公共符号始终要注释，需要提供上下文信息，对所有函数以及公共的符号提供注释。
代码格式：
gofmt可以自动格式化代码，Goland自动进行格式化。 goimports还可管理依赖包。
注释：
应该解释代码的作用、实现过程、实现原因（外部因素、上下文都要提供）以及代码什么情况会出错（限制条件有哪些）。 清晰地描述对外使用的函数
命名规范：
个人理解：我们应该让命名有助于其他人的阅读使用
变量命名
- 简洁胜于冗长：如写简单的for循环时，可以用 i 而非 index，此时index的冗长没有增加对程序的理解
我的思考：在和其他人的接触中经常看到有人批判for循环中使用i下标的做法，其实应该分情况讨论。当循环仅仅只是代表相应次数时，使用i下标无可厚非，否则就应该写清下标变量。
- 缩略词应全大写（例如ServeHTTP 而不是 ServeHttp），但当位于变量开头且不需要导出时应该全小写（使用XMLHTTPRequest 或者 xmlHTTPRequest）；
- 变量距离其被使用的地方越远，则需要携带越多的上下文信息（如全局变量）。
个人理解：离得越远查询越麻烦，携带更多信息有助于理解与记忆
- 传参：
使用deadline比t好，deadline表明截止时间，t表示任意时间，此时前者更好
函数名命名
- 函数名不携带包名的上下文信息，因为包名和函数名总是成对出现的 如http.serve() 调用，没必要把serve命名成serveHTTP。
- 函数名尽量简短
- 当名为foo的包某个函数返回类型Foo时，可以省略类型信息而不导致义
- 当名为foo的包某个函数返回类型T时（T并不是Foo），可以在函数名中加入类型信息
包名命名
- 只由小写字母组成。不包含大写字母和下划线等字符
- 简短并包含一定的上下文信息。例如schema、task等
- 不要与标准库同名。例如不要使用sync或者strings
- 以下规则尽量满足，以标准库包名为例
- 不使用常用变量名作为包名。例如使用bufio而不是buf
- 使用单数而不是复数。例如使用encoding而不是encodings
- 谨慎地使用缩写。例如使用fmt在不破坏上下文的情况下比format更加简短
个人理解：好的包名可以保证调用的简洁性和理解的便易性
控制流程
保持正常代码的路径为最小缩进 对异常情况提前返回
个人理解：控制流程中如果把正常语句放在最底层嵌套中，将严重影响代码可读性，以前写代码难以阅读也有一部分原因如此
应该改为
错误处理
在学习中错误处理更常见于简单程序中
简单错误优先使用errors.New 错误判断可以使用 errors.Is
