Clean Code 笔记
Why clean code matters
糟糕的代码现在看起来也许没什么要紧，但是过个两三年，就回发现，改起来困难重重。
维护一份干净的代码不仅仅是为了现在，也是为你的职业着想，想想要是在糟糕的代码里工作会是什么感觉。
要知道，糟糕的代码是你写的，所以没有理由责怪其他人，不管是上头催促还是时间太紧。
What is Clean Code
优雅，简单、直接，读起来像优美的散文，意图明显，可读性强，表达性强，没有重复，不做多余的事情。
散文的特点是形散而神不散，各个组成部分是相互独立的，但是之间有起承转合，行云流水，而不是一坨互相矛盾，重复的话语，神不散，言之有物。散文的另外一个特点是短小精炼。
好的代码是需要心力的，你可以在代码里看到作者苦思冥想到最后完成作品的那种喜悦。
Meaning Names
名字要有意图
int d; // elapsed time in days
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
避免传递错误信息
accountList
如果accountList是个set， 会不会很恼火？
名字的区别要有意义
ProductInfo和ProductData的区别在哪里？
不要让两个相似的名字做看起来相同的事情
名字可发音
可以让阅读代码更流畅；便于交流
Long variable name for long scope, short variable name for short scope.
Nice short name for public function(long scope,called by many places),
long name for private function which explain what it does by name.
Function name rules apply to class name too.
函数
短小精炼
Three or four lines?
我觉得几行没有什么硬性的规定，一个function应该做到言简意赅，不要做多余的事情。
块和缩进
嵌套不宜多层
只做一件事
一件事的定义？
Switch statement
Using polymorphic for switch
函数名自描述性
从函数的名字就可以知道函数在做什么，不要有surprise
avoid output argument
函数参数
最多3个
No flag args
因为它至少做了两件事，true & false
参数对象
将参数包装成对象
CQS
Command change sth(tell), query compute sth(ask).
Law of Demeter(What the benefit, what it solves?)(为了降低耦合)
You may call methods of objects that are:
- Passed as arguments
- Created locally
- Instance variables
- Globals
You may NOT call methods of objects that are:
- Returned from a previous method call
参考资料
http://www.bradapp.com/docs/demeter-intro.html
http://pragprog.com/articles/tell-dont-ask
注释
注释应该用来解释代码的原因，比如为什么选择ArrayList而不是LinkedList。
格式
变量声明
什么时候用，什么时候声明
实例变量
声明在一块地方
函数之间有互相依赖
调用函数的函数在被调用函数的上面
概念上相似的函数放在一块
一行代码不要超过100个字符或120个字符，千万不要有横向滚动条
团队要有代码规范
对象和数据结构
面向过程的代码添加新的函数不需要改变现有的数据结构，面向对象的代码添加新的类不需要改变现有的函数。
面向过程的代码添加新的数据结构比较难，因为所有的函数都要改，面向对象的代码添加新的函数比较难，因为所有的类都要改。
边界
依赖接口，而不是依赖具体实现
TDD
我觉得测试的作用一部分是保证现在写的代码在测试条件下没有问题，二是为了重构(eliminate the fear)。
类
public static variable
private static variable
private instance variable
public function
private helper function
Rule
类应该足够小(职责来划分)
SRP
一个类应该只有一个职责，也只有一个改变的原因
当你发现一个类，有两个改变的原因的时候，就是重新划定职责的时候。
系统
(Architect is about usage)架构是关于使用
架构跟交付的方式无关
Separation of concerns
Dependency Injection
