我们都曾经瞟一眼自己亲手造成的混乱，决定弃之不顾，走向新的一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强，我们都曾经说过有朝一日再回头清理。当然，在那些日子里。我们都没有听过布朗法则：later equals never 稍后等于永不.
看到这句话确实有点惭愧。印象最深的感觉就是，我们去看一两年前自己的代码，真的是自己都看不下去。要让我改，我情愿再实现一个。所以时刻保持好的习惯是多么重要。不要想着以后再解决。就像领导说，这个事情以后再考虑，然后就没有然后了
第一章 整洁代码
怎样是整洁的代码？
代码作品就像艺术品一样，有不同的流派，在大师的眼里，对于优美与漂亮有不同的理解。关于什么是整洁代码书中讲述很多大师的观点，各个侧重点不同。
Bjarne Stroustrup 说：
“我喜欢优雅和高效的代码，代码逻辑应当直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没有必要的优化，搞出一堆混乱来，整洁的代码只做好一件事。”
Ron Jeffries 对整洁代码的理解：
1.能通过所有的测试。
2.没有重复代码。
3.体现系统中的全部设计理念。
4.包含尽量少的实体、比如类、方法、函数等。
5.尽量少的依赖关系，便于维护。
6.整洁的代码浅显易懂，绝不故作高深；
“在以上诸项中，我最在意的是代码重复。如果一段代码重复出现，就表示某种想法未在代码中得到良好的提现。我会尽力去找出到底那是什么，然后在尽力的更清晰的表达出来。”
总结下就是整洁的代码：1.职责明确，没有多余。2.减少依赖，便于维护。3.高效。
第二章 有意义的命名
1.名副其实。 说起来很简单。选个好名字需要花时间，但省下的时间比花掉的多。注意命名，一旦有好的命名，就换掉旧的。
int d;//消失的时间，以日计。int elapsedTimeInDays，int daysSinceCreation;
我们定义不同的变量，能够看到名字就知道是什么意思，这是最基本的要求了。
2.避免误导。比如不是List类型，就不要用个accountList来命名，这样形成误导。
3.做有意的区分。
Public static void copyChars(char a1[],char a2[]){
for(int i=0;i<a1.length;i++){
a2[i]=a1[i]
}
}
如果参数名称改为source和destination ，这个函数就会像样很多。废话都是冗余的，Variable一词 永远不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString 会比 Name好吗，难道Name 会是一个浮点数不成？如有一个Customer的类，有又一个CustomerObject的类。是不是就凌乱了。
4.使用便于搜索的的名称
单个字母或者数字常量是很难在一大堆文章中找出来。比如字母e，它是英文中最常用的字母。长名胜于短名称，搜得到的名称胜于自编的名称。 窃以为单字母的名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。
5.类名应该是名词或短语
像Customer，Account，避免使用Manager,Processor,Data或者Info这样的类名。类名不应当是动词。方法名应该是动词或动词短语，如postPayment ,deletePage或Save，属性访问、修改和断言应该根据其值来命名，并加上get，set，is这些前缀。
6.别扮可爱,耍宝
比如谁知道HolyHandGrenada 函数是干什么的，没错这个名字挺伶俐，但是不过DeleteItems或许是更好的名字。
7.每个概念对应一个词。并且一以贯之。
在一堆代码中有Controller，又有manager，driver。就会令人困惑。比如DeviceManager和Protal-Controller之间又什么本质区别？
第三章 函数
1.函数的第一规则是要短小，第二条规则是还要更短小。
2.函数应该做一件事。做好这件事。只做这一件事。
3.尽量少的函数参数。有两个参数的函数要比一元函数的难懂。如果需要三个或者三个以上的参数应该封装成类了。
4.不要重复自己。
如果一段相同的代码出现了两次，你是不是觉得自己改做些什么了。
第四章 注释
注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。事实上注释是一种失败，我们总无法找到不用注释就能表达自我的方法，所以总要有注释，这并不值得庆贺。写注释的常见动机之一是糟糕代码的存在。带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎而复杂的代码像样的多。与其花时间编写解释你搞出的糟糕的代码注释，不如花时间清洁那堆糟糕的代码。
好注释：
1. 法律信息。有时，公司代码规范要求编写与法律有关的注释。例如版权和著作申明。
2.提供信息的注释。
//Returns an instance of the Responder being
protected abstract Responder responderInstance();
不过将函数名重新命名为 responderBeingTested 注释就是多余的。
3.对意图的解释。 有时注释不仅提供了有关实现的有用信息，而且还提供了某个决定后面的意图。
4.阐释。 有时注释把某种晦涩难明的参数或返回值的意义翻译为某种可读形式。也会是有用的。特别是参数或者返回值是某个标准库的一部分，或者你不能修改代码，那帮助阐释其含义的代码就会有用，例如:
assertTrue(bb.compareTo(ba)==1); // bb>aa
assertTrue(a.compareTo(b)== -1); // a<b
直接看方法可能不明确，但有注释就明白多了。
5.警示，告诉别人要注意这个方法之类的。
6.放大。有的代码可能看着有点多余，但编码者当时是有他自己的考虑，这个时候需要注释下这个代码的重要性。避免后面被优化掉。
网友评论