代码整洁之道阅读笔记02
第二次阅读，阅读了第四章到第九章
整理部分如下：
第四章：--注释
什么也比不上放置良好的注释来的有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。
真实只在一处地方有：代码。代码能忠实地告诉你他做的事。，那是唯一真正准确的信息来源。所以，尽管有时也需要注释，我们也该多花心思尽量去减少注释量。
注释不能美化代码。
相比于对函数做解释的注释，通过函数名称传达信息会更好。
不需要的代码直接删掉。
第五章：--格式
选用一套管理代码的简单规则，然后贯彻这些规则。如果在团队中工作，则团队应该一直同意采用一套简单的格式规则，所有成员都要遵从。
第六章：--对象与数据结构
第七章：--错误处理
错误处理很重要，但如果他搞乱了代码逻辑，那就是错误的做法。
别返回null值，返回null值，基本上是在给自己增加工作量，也是在给调用者添乱。
将错误处理隔离看待，独立于主要逻辑之外。
第八章：--边界
第九章：--单元测试
单元测试让代码可扩展、可维护、可复用。
整洁的测试：可读性！！--明确、简洁还有足够的表达力。
五个规则：
快速，测试够快。
独立，测试应该相互独立。测试不应该为下一个测试设定条件，单独运行每个测试，及以任何顺序运行测试。
可重复，测试应该在任何环境中重复通过。
自足验证，测试应该有布尔值输出。
及时，测试应该及时编写。单元测试应该恰好在使其通过的生产代码之前编写。
个人感受
这一部分阅读一开始就看见：什么也比不上放置良好的注释来的有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。
开始一章写的关于注释，其实从大一刚刚开始接触编码的时候，就听老师一直说要写注释写注释，但是自己基本没有写过注释，真的没有养成这个习惯，有的时候写注释，感觉自己都是在做一些没有用处的活，花费很多时间，也很麻烦，写代码的时候觉得自己看得懂代码，但是真的不写注释，再过一段时间去看的时候自己真的不是很懂当时写的代码，看完这几个章节，自己才发现，其实写了注释最后过一段时间再看，其实也不一定会懂，因为自己其实代码不仅仅是命名还是编码规则都不是很清楚，加上注释再去看其实很多地方也不是很明白，看完这一部分我觉得其实注释就是解释你使用代码表达不出来的东西。可是，我的代码表达不出来的东西太多了。要写的注释也很多，要写关键的注释，就要先提升关于自己的代码的可读性，真的让自己的很多代码都能表达出自己的意思，在这一部分上面，很多的注释就不用写了，
就像作者说的写多余的注释、误导性注释、循规式注释、日志式注释、废话注释，还不如花时间整理自己的代码，通过代码表达自己想表达的内容。
代码格式关乎后期维护代码的可读性以及对代码的可维护性和扩展性。在写程序时，经常会使用开放源代码和购买第三方程序包。
改进点：
用一套简单的代码规范，来提升自己代码编写的格式规范，命名规则，增加代码可读性；
多做测试，做一小部分就测试几遍，不要等最后在一起测试.