代码整洁之道，Clean Code，作者是美国的Robert C.Martin，写这个我只是为了提高这本书的格调~~
这本书是我前一段时间读的，读过之后对我编程有很大的影响，建议程序员同志们阅读一下。简单说一下我从里面收获的最重要的观点，做个简单的书摘，欢迎讨论~~
1. 有意义的命名
这个对于程序员来说并不陌生，但是什么样才算做有意义书里进行了详细的讲解。
（1）避免误导：比如accountList表示一组账号，如果它并不是List类型，那么就会引起错误的判断，因为List对程序员来说是一个特殊的类。
（2）没有废话、不冗余：比如Variable永远不应该出现在变量名之中。
（3）读起来清晰易懂：比如某家公司中有genymdhms这样一个函数（表示生成日期、年、月、日、时、分、秒），读起来晦涩，简直是糟糕的命名方式。
（4）便于搜索：比如某个变量表示一周的天数，用7这个数字远远不如定义一个A_WEEK_DAYS这样的常量容易被搜索到进行修改或者查询。
（5）命名增加变量类型：比如String strTemperature中的str表示变量类型，这个在实际阅读过程中会被忽略，在编程过程中也并没有起到很好的作用，反而增加了修改代码的难度和阅读代码的难度。这里我个人经常写android的时候这样用，主要是用于区分控件，因为一个界面的控件名比较容易重复，所以我个人觉得如果从命名区分的角度来讲还是可以加类型的。
（6）符合普遍思维，不用双关语：比如add、insert、append之间的区别要搞清楚，对于方法的命名要清晰。
2. 函数
函数的写法和命名是决定这整个程序是否易读的关键点。
（1）短小：曾经说函数不应该超过一屏，后来说20行封顶最佳，实际上一个函数应该做的就是做一层的工作，相当于一个while，或者一个if、else结构，要缩到最短才是合格的函数。当然比如说像android中findviewbyid()这种需要大量copy的代码，自然要很多行，其实文中的意思是要缩短一个函数的逻辑长度，所以对于逻辑函数应该不超过10行左右。
（2）只做一件事：比如显示一个手机屏幕上的控件函数，需要显示所有的TextView和所有的Button，那么这就是两件事儿，要分成两个函数来写，不能混在一起。
（3）函数参数：最理想的是零参数函数，其次是一，再次是二，应尽量避免三，有足够特殊的理由才能使用三个以上参数。主要原因在于，一旦有参数就需要你了解函数更多地细节，从测试的角度来说更叫人为难，参数越多测试用例越复杂。
（4）标识参数：标志参数丑陋不堪，向函数传入布尔值简直就是骇人听闻的做法。这样做大声宣布函数不止做一件事，违反了第二条，应该将其分为两个函数分别调用。
（5）参数对象：如果函数看来需要两个、三个或三个以上参数，说明其中一些参数应该封装为类了。
（6）使用异常代替返回错误码：不要用一层层的if、else在不同的情况去输出不同的错误码，而应该用异常直接获取错误，代码整体立马简洁易读。
（7）错误处理就是一件事：因为函数应该只做一件事，所以错误处理就是一件事。
放个图，解释一下什么叫做简洁的函数：
3. 注释
文中有一个对于注释非常鲜明的观点，这句话是这样的：注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败！注释是一种失败！因为找不到不用注释表达自我的方法，所以要有注释，这并不值得庆贺。
为什么要极力贬低注释？因为注释会撒谎，注释存在的时间越久，离其所描述的代码越远，越来越变得全然错误，原因就是程序员不能坚持维护注释。比如我自己代码中的一个例子：
注释不能美化糟糕的代码
用代码来阐述不要用注释
下面讲讲好注释都可能有哪些：
（1）法律信息，不过更好的是指向一份标准许可或者其他文档；
（2）表示返回值含义，不过其实也可以用函数命名来弥补；
（3）或者解释某种临时的解决方案；
（4）警示使用该代码的后果；
（5）todo注释，表示应该做但是还没做的事情，但是这是必须立刻解决掉的注释。
再带大家看看坏注释都有什么。
（1）喃喃自语。。。
（2）多余的注释，如下图，读这段注释花的时间没准比读代码花的时间还要长
（3）循规式注释，如下图，非要给函数加上注释解释变量含义。
（4）日志式注释，如下图，在已经有源代码控制系统可用的今天，这种冗长的记录只会让模块变得凌乱不堪，应当全部删除
（5）废话注释：如下图，不多说了，看看就懂了
（6）归属与署名：比如在代码中标注了哪里是自己修改的
（7）注释掉的代码：其他人不敢删，只会长期堆积，变成一堆垃圾
我可以说我看完这篇之后，就基本很少写注释了。
