Clean Code Rule:
有意义的命名
1. 名副其实，能够通过名称知道变量、方法的作用意义;
2. 避免误导，避免留下掩藏代码本意的错误线索;
3. 做有意义的区分;
4. 使用读的出来的名称;
5. 使用可搜索的名称;
6. 避免使用编码，把类型或作用域编进名称里面，徒然增加了解码的负担;
7. 避免思维映射，不应当让读者在脑中把你的名称翻译为他们熟知的名称;
8. 每个概念对应一个词，给每个抽象概念选一个词，并且一以贯之;
9. 添加有意义的语境，用有良好命名的类、函数或命名空间来放置名称。
函数
1. 短小，函数的第一规则是要短小;
2. 只做一件事;
3. 每个函数一个抽象层级，函数中的语句都要在同一抽象层级上;
4. 使用描述性的名称，命名方式要保持一致;
5. 函数参数，最理想的参数数量是零， 我们不太期望信息通过参数输出;
6. 无副作用，不做预期以外的行为;
7. 分隔指令与查询，函数要么做什么事，要么回答什么事，但二者不可得兼;
8. 使用异常替代错误返回码，错误处理代码就能从主路径中分离出来;
9. 别重复自己，重复可能是软件中一切邪恶的根源;
10. 结构化编程，每个代码块尽量做到一个入口、一个出口。
注释
1. 注释不能美化糟糕的代码;
2. 用代码来阐述，很多时候，简单到只需要创建一个描述与注释所言同一事物的函数即可。
格式
1. 垂直格式，变量和函数应该在靠近被使用的地方定义;
2. 横向格式，遵循无需拖动滚动条到右边的原则。
面向对象设计的原则（SOLID）
1. 单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因;
2. 开放-封闭原则（OCP），软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改;
3. Liskov替换原则（LSP），子类型必须能够替换掉他们的基类型;
4. 依赖倒置原则（DIP），抽象不应该依赖于细节，细节应该依赖于抽象;
5. 接口隔离原则（ISP），不应该强迫客户依赖于他们不用的方法，接口属于客户，不属于它们所在的类层次结构。
单元测试（必需）
1. 保持测试代码的整洁，和产品代码一致的质量要求;
2. 每个测试Case只测试一个场景;
3. 整洁的测试遵循F.I.R.S.T.规则：
a. 快速（Fast），测试应该能够快;
b. 独立（Independent），测试应该互相独立;
c. 可重复（Repeatable），测试应当在任何环境中重复通过;
d. 自足验证（Self-Validating），测试应该有布尔值输出表述通过或失败;
e. 及时（Timely），测试应及时编写。
迭代
1. 通过迭代设计达到整洁目的；
2. 提倡频繁的检入代码和UT；
3. 鼓励按TDD方式写UT，TDD三原则：
a. 在编写失败的单元测试之前，不可编写相应的产品代码；
b. 单元测试做到刚好失败或编译错误，不做额外编写；
c. 产品代码刚好足以通过当前失败的测试，不做额外编写。
沪ICP050146651号-2
上海市互联网违法与违规信息登记中心
