代码整洁之道阅读笔记01
第一次阅读，阅读了序，前言和前三章。
整理部分内容如下：
序：
丹麦谚语：小处诚实非小事。以小见大。
5S哲学：
整理--组织，搞清楚事物之所在，通过恰当的命名之类的手段；
整顿--整齐，每段代码都应该在你希望他所在的地方，如果不在了，就需要重构了；
清楚--清洁，四处遗弃的带注释的代码及反映过往或期望的无注释代码，除之而后快；
清洁--标准化，开发组内使用一贯的代码风格和实践手段，标准在哪？
身美--纪律，在实践中贯彻规程，并实时体现在于个人工作上，并且要乐于改进。
正文：
勒布朗法则：稍后等于永不。
Ron：
有意义的命名时体现表达力的一种方式；
整洁代码：消除重复，提高表现力，提早构建简单抽象。
“深合己意”的代码：无需花太多力气，明确，简单，有力。
名副其实：使用指明了计量对象和计量单位的名称；
避免误导，名称选用不同之处大的；
名称：提供正确信息，提供导向作者意图的线索，有意义的区分，能读得出的，
明确是王道，编写别人能理解的代码；
类名和对象名应该时名词和动词短语，类名不应当是动词，避免使用没有明确意义的和没有区分的类名。
方法名应该是动词和动词短语，属性访问器、修改器和断言应该根据其值来命名，并依Javabean标准加上get、is、set前缀。
函数名称应当独一无二，并且保持一致。
函数：
1.短小
2.只做一件事
3.每个函数只有一个抽象层级
函数参数：最理想的是零个，其次是一个，再次是两个，尽量避免三个及以上。
别重复自己的代码！！！
个人感受：
本书以图片开头，提问：你的代码在哪道门后面？
看到这里，我自己首先愣住了，不可避免的想选择Good Code那一扇门，但不得不承认，自己的代码还是在Bad Code代码那一扇门后面的。
其实勒布朗法则给我很深的感受，稍后等于永不。很真实的状况，我们也可以说是拖延，经常遇到一件事情现在不想去做，就想着稍后去做，结果这件事情根本就不会再做。例如经常会做的课堂小测，每一次下课的时候总是会一六一些问题，自己每一次都是计划着回宿舍了就开始做，查代码的Bug，但是从来没有在做过，往往都是开始写作业或者完成任务的时候才开始真正的去做，好好的看看自己遗留的问题，改代码。其实，有些问题可能就是当时来的一点灵感，或者当时有的小问题，下次再一次去看代码可能就不会再遇见这个问题了。
后面看到一些关于变量，类，方法等的命名规则，我也是深有感触，团队一起做项目，总需要完成的任务就是整合代码，将两个甚至是多个人的代码整合到一个人电脑项目里面，每次到了这个时候，简直就是重灾区，每次都是很不顺利，有一个问题其实之前就知道，就是关于文件名变量类等的命名每个人的习惯都不一样，都有一套自己的命名方法，最后在整合代码的时候，就会出现变量名重复、互相看代码却看不懂等等问题，都阻碍了我们整合代码，往往一个小问题都能让我们在整合代码的路上停留很长时间。
方法：
在做团队项目之前，先和自己的队友一起开会，统一关于文件、变量、类、函数等的命名规则。