王国里的工匠在一个古老的王国里，有两位建筑工匠，他们是石丰和屠。就实际经验而言，他们的技术差不多。不同的是，石丰以他的& quot效率& gt；想盖房子，找他只要一个月。土方师以& quot稳定性& quot。他总是在破土动工前把事情安排妥当。风事业部完成项目只需要一个月，土事业部需要三个月。

风师有一个大麻袋。这是他的宝箱。他所有的工具都在里面。他把锤子命名为1号，斧子命名为2号。这样，他工作时只需喊出一个简短的名字：1号用于固定，2号用于伐木.用完后，他会把所有的工具放回袋子里。风师总是带着麻袋来，带着麻袋去。不要拘泥于形式，无论在哪里与公牛赛跑。风大师常说：这就是& quot效率& gt；

地球工程师有很多工具箱，每个工具都放在自己的类别里。他从未给tools起别名或缩写。锤子叫锤子，斧子叫斧子，甚至更细。向下又细分为羊角锤、检锤、山斧、板斧等。地球老师总是在开始工作前大惊小怪，但他的工作从来没有过分过，令人钦佩。

风主每天总是很忙，一个又一个项目甚至排到了明年。当人们建造房子时，他们只是想要这个词& quot快速& quot。相比之下，地球事业部的业务似乎是空的。往往是风大师的作品不够用的时候，才会有人找土大师帮忙打造。久而久之，人们就默认了风师的技能高于土师。一大家子人动工时，都以请风师为荣，又因为风师总是背着他的大麻袋，所以被尊称为& quot金麻袋& quot。石丰赚了很多钱，成了王国里的一个小富户。但地球老师依然不慌不忙，认真地做着自己的工作。

王国几十年来风调雨顺，国库日益充实。国王喜出望外。这一天，国王决定扩建宫殿。关白向国王推荐了石丰和屠氏。

国王邀请了两位工匠，命令他们建造一个凉亭作为测试。

风师傅背上他的大麻袋，准备好建筑材料后，施工开始了。10号碎石，15号打桩.风师操作流水，但由于他的工具号只有自己熟悉，别人很少能帮上忙。国王看着风师的操作，渐渐皱起了眉头。

地球大师一个一个打开他的工具箱，当他所有的工具都准备好的时候，风大师已经开始打基础了。然后地球老师开始建凉亭。他指挥建筑工人用砂浆机搅拌砂浆，龙门架把它吊起来.看着地球老师有条不紊的指挥，国王的眉头渐渐舒展开来，眼里流露出赞许。

最终，还是花了三倍于此的时间才完成了展馆的建设，但是国王决定任命大地大师为宫殿建设的皇家工程师。

众官大惑不解，只听国王说：风师和土师的技艺妙不可言，都是王国里的能工巧匠。但是风师做事很随便，工具也很乱。宫殿的扩张是巨大的，当人数逐渐增加时，这个规律就会混乱。相比之下，风老师只能生活在一个角落，土老师可以承担这个伟大的任务。

后来地球师的表现正好印证了国王的话。在地球师的指挥下，宫殿的扩建只用了一年时间。这座新建的宫殿雄伟壮观，安全可靠。当人们感到震惊时，他们才想起地球部处理的项目，无论大小，似乎都不会超过一年。虽然石丰以速度著称，但当他负责一座中型建筑时，往往会推迟到两年左右。负责小楼是可以接受的。当格局扩大时，地球老师是最& quot高效& quot人。

这个故事的寓意很简单，工程的质量和效率离不开良好的建筑习惯。当我们负责一个小项目的时候，我们追求速度，力求速效。此时，我们

在软件开发中也是如此，干净的地板可以减少事故，工具到位可以提高生产率。软件质量不仅取决于架构和项目管理，还取决于代码质量。代码质量与其整洁度成正比。干净的代码不仅质量可靠，也为后期的维护和升级打下了良好的基础。

破窗理论与童子军追赶型犯罪心理学中有一个破窗理论。以一栋有几扇破窗户的建筑为例。如果那些窗户不及时修复，可能会有破坏者破坏更多的窗户。最终，他们甚至会闯入大楼，如果他们发现没有人住，他们可能会在那里定居或放火。一面墙，如果有一些没有清理干净的涂鸦，很快就会被脏乱不堪、不堪入目的东西覆盖；一条人行道上有一些纸屑，很快就会有更多的垃圾，最终人们会自然地把垃圾扔在地上。

这个问题在编程中经常出现。当我们接手一个混乱的代码时，如果不及时整理，最终会导致越来越多的混乱。这是一个基本的价值困惑，之前的困惑和期限压力让开发者不断制造困惑。当我们审查代码时，我们听到最多的借口是：那是前一个人写的。其实问题的关键是他们没有花时间让自己做的更快。

美国童子军有一个简单的追赶：让营地比你来时更干净.

清理代码的方法可能只是更改一个变量的名称，拆分一个有点太长的函数，消除一点重复的代码，清理一个嵌套的if语句。在梳理代码时，请记住这一点：每次review代码,让代码比你发现它时更整洁.

一、谨慎命名

给函数和变量起个好名字是优秀程序员的基本功。命名的基本要求是名副其实和见文知意.如果名字需要补充注释，那就不是一个好名字。

可变//日期更改为

vardate

取名的第二个要求是避免误导。比如数据本身不是一个list，那就别用list来命名，因为list一词对程序员有特殊的含义。

修改为：

取名的第三个要求是去掉冗余。Variable一词永远不应当出现在变量名中，Table一词永远不应当出现在表名中。nameString会比name好吗？ProductInfo、ProductData和Product有什么区别？更糟糕的是，如果代码中同时存在Article和ArticleInfo类，程序员怎么知道该调用哪个类呢？多个意义含混的冗余词汇只会让阅读者困惑，要区分名称，就要以读者能鉴别不同之处的方式来区分。

例如：开始你用了address变量表示用户居住地，如上海、北京。后来又要求更详细地描述用户的居住地。如上海黄浦区、浦东区，北京海淀区、朝阳区。用什么来命名这个详细地址呢？detailAdress？smallAddress？还是anotherAddress？这些统统都不是好的做法，牢记上述法则：以读者能鉴别不同之处的方式来区分，这时比较好的做法是修改之前的address变量名字为city，再将区域的地址命名为district。

取名的第四个要求是：严谨，不要俏皮。笔者曾经接手一位外国同事写的代码，在一个类中，这位外国同事使用了wearClothes、wearPants命名函数，之后又出现一个startParty函数。仔细理解后，笔者才发现，这是代表软件系统的第一步准备、第二步准备，然后正式启动这三个流程。或许这位同事写这个类时心情不错，将其比喻成了一个party的流程，但对于读者来说，梳理这三个函数的意思着实要费一番心思。事实上，此时我们最好将其命名为firstStepOfPreparation、secondStepOfPreparation、systemBoot，宁可明确，毋为好玩。

二、函数和类

函数和类应该坚持单一权责原则。保持高内聚，低耦合。隔离会让系统每个元素的理解变得容易。

单一权责原则：在面向对象编程领域中，单一权责原则（Singleresponsibilityprinciple）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。一个类或者模块应该有且只有一个改变的原因。

过长的函数会造成不易理解，如果某天这个函数需要修改的话，一个长长的函数会大大增加理解成本。并且，小函数也能更好地复用。

如果一个函数做了多件事，一个明显的标志是无法为它起一个精准的名字。你会觉得需要函数名需要使用and连接，比如calculateAndPrintPrice，这时候最佳做法是将其拆分为calculatePrice和printPrice两个小函数。

函数的第二个规范是尽量不要在参数中传递状态值，状态值是函数做了多件事的明显标志。例如：

修改为：

函数的第三个规范是同一个函数中的代码应该属于同一层级。良好的软件设计要求分离位于不同层级的概念，较低层级概念和较高层级概念不应混杂在一起。

修改为：

三、坏注释与好注释

注释并不是越多越好，有的注释纯属无意义的废话，例如：

这些注释看起来就像是喃喃自语，或许读者阅读这些注释的时间比读代码还要长。

好的注释只应该用在必要时，用于警告其他程序员会出现某种后果的注释是有用的，例如：

但，最好的注释是没有注释，若代码足够有表达力，用代码来展示意图往往会更好。注释总是一种失败。当我们无法找到不用注释就能表达自我的方法时，我们写了注释，这并不值得庆贺。因为注释常常会撒谎。原因很简单：程序员不能坚持维护注释，尤其是别人写的注释。当另一个人修改了代码后，往往不会去阅读上一个人写的注释，再修改注释。所以注释常常会与其所描述的代码分割开来，孑然飘零，越来越不准确。

写注释的常见动机之一是原有代码混乱。当我们阅读代码时，发现已有的代码令人困扰、乱七八糟。这时我们也许会告诉自己：“等我阅读清楚后，给它写点注释！”别那样做！最好的做法是把代码整理干净。

修改为:

四、良好的格式

在我们阅读报纸时，在顶部，你期望有个头条，告诉你故事的主题。然后第一段是整个故事的大纲，给出粗线条概述，但隐藏了故事细节。接着读下去，细节渐次增加，直至你了解所有的细节。

代码的格式也要像新闻文章一样，最顶部给出高层次概念，向下渐次展开细节。函数应该紧跟调用处，保证垂直方向上的靠近。如果格式混乱，读者在阅读时总会滑上滑下，导致思维跳跃，增加不必要的理解难度。

影响格式的第二个要素是缩进与间隔，现代化的IDE都有格式化代码快捷键，你也可以在设置中搜索"ReformatCode"，自定义格式化代码快捷键。随时格式化，并去掉多余的空行，让我们的代码保持清爽、整洁。

五、数据结构

在有的源代码中，作者采用长长的链式调用，甚至会鼓吹自己只写了一行代码便实现了此功能。事实上，绝不应该为了节省变量，写过长的链式调用，否则容易造成"火车失事"。正确的做法是遵守“得墨忒定律”：适当拆解链式调用，只和朋友谈话，不和朋友的朋友谈话，使得代码阅读和调试都更方便。

得墨忒定律（TheLawofDemeter）：模块不应该了解它所操作对象的内部情形。

修改为：

六、错误处理

在处理程序异常时，我们常常会用到try/catch代码块，而try/catch代码块丑陋不堪，他们搞乱了代码结构，把错误处理与正常流程混为一谈。最好的做法是把try和catch代码块的主体部分抽离出来，另外形成函数。错误处理就是一件事。

现代化的语言都有异常机制，异常情况如果不及时加以处理，可能会导致程序崩溃。所以有的程序员对于程序的异常情况会选择返回0或者-1等错误码，以保持程序不崩溃。

别这样做，正确的做法是将错误码替换为抛出异常，只有这样才能保证出现错误时立马就可以发现，而不是让程序在错误的状态下继续执行，将来造成更加迷惑的错误。

要讨论错误处理，就一定要提及那些容易引发错误的做法。第一项就是返回null值。我不想去计算曾经见过多少几乎每行代码都在检查null值的应用程序。返回null值基本上就是在给自己增加工作量，也是在给调用者添乱。只要有一处没有检查null值，应用程序就会失控。返回null不如抛出NullPointerException，或是替换为一个空对象。让调用者不再需要检查null，代码也就更整洁了。