衡量代码质量的（这里我理解是不包含性能的）唯一标准就是别人阅读你代码的感受。
什么样的代码是整洁的
- 清晰（是什么，做了什么，一眼看得出来）
- 简单（职责少，代码少，逻辑少）
- 好拓展（依赖的比较少，修改不会影响很多）
不整洁的代码阅读体验
- 乱（组织乱，职责乱，名称乱起）
- 逻辑不清晰（if-else 太多）
- 难修改（耦合严重，各种写死）
个人对写出整洁代码的一些经验
1.清晰
1-1.取个好名字
- 名副其实
阅读名称就知道它为什么存在、做什么事、应该怎么用，如果需要通过注释来回答，那就不算名副其实
- 不容易混淆
避免使用非常相似的名称，尤其是类型还相同，比如小写 l 和1、o 和 0、专有名词
- 读的出来
不要因为害怕名称过长而使用缩写，那样不便于和别人讨论
不整洁代码的特点:使用缩写（让使用者误解其用途）;描述性差（通过命名无法理解他的作用）;使用专业术语做名称;
google命名约定网址：zh-google-styleguide.readthedocs.io/en/latest/g…
1-2.通用的代码目录结构
1-3.定义接口(go的经验)
不仅仅是为了实现多态，也让人能清晰的知道这个go文件干了什么事！
1-4.通过注释
- 提供信息
提供代码以外的信息，如产品信息等
- 复杂实现的简要概括
让阅读者快速了解某个复杂的系统
1-5.格式化代码
- 团队最好统一格式化标准
- 一行代码列数不超过 100
- 用好空行
2.简单
2-1.函数简洁
- 函数的第一要则：短小
个人习惯是不超过20行(不算空格的情况)
- 只做一件事
要判断函数是否做了不止一件事，就看它里面的代码，是否能再拆出一个函数
- 定义的函数的参数越多，你耗费函数使用者的青春就越多，使用者需要花时间搞清楚每个参数的具体含义和顺序
最理想的参数数量是 1~2 从测试的角度看，参数越多，可能出现的用例就越多，就越容易出错 保持参数列表短小的方法: 参数升为全局变量、多个参数封装成一个struct
2-2.类简洁
- 类也要求短小
个人认为判断一个类能干多少事就看命名的时候是否符合单一原则
- 类里干的事要和命名相对应
如果类里有名称之外的职责，建议拆分
3.好拓展
- 个人理解其实就是要做到高内聚，低耦合——你的模块或者说类，如果能满足单一原则，只干自己的份内之事，那么应该是满足高内聚的；如果两个不同的模块之间确实存在引用，那么个人建议是每个类都应该依赖抽象而非具体,减少对外暴露公有变量,使用 getter(new)代替。
之前写java时的继承，多态这些设计思想其实也都是为了实现简洁的类达到高内聚低耦合这个目的
