王国的工匠师
在一个古老的王国里，有两个建筑工匠——风师与土师。就实操履历而言，他们的技艺相差无几。差别在于，风师以“效率”有名，若你要修一栋屋子，找他仅需一月韶光便可完成；土师以“稳定”有名，他总是将东西归置整洁后，方才破土动工，风师只需一月完成的工程，土师须要三个月。
风师有一个大麻袋，这是他的百宝箱，他所有的工具都在里面。他把锤子命名为 1 号，斧子命名为 2 号。这样他事情时，只需叫出简短的名字：1 号拿来固定，2 号拿来伐木……用完之后，将所有工具收回麻袋。风师总是背着麻袋来，背着麻袋去。不拘泥于形式，不管哪里都洒脱走一回。风师常说：这便是“效率”的窍门。
土师有非常多的工具箱，每种工具都放在自己的种别里。他从不给工具起别名或简称，锤子便叫锤子，斧子便叫斧子，乃至更为详细。向下又细分为羊角锤、考验锤、开山斧、板斧等等。土师开工前总是调兵遣将，但他的事情从未出过大的疏忽，倒也令人钦佩不已。
风师每天总是业务繁忙，一个接一个的工程乃至排到了明年。百姓修屋子，就图一个“快”字。比较之下，土师的买卖就显得门可罗雀了。常常是在风师的活接不过来时，才有人请土师来帮忙建造。久而久之，人们已经默认风师的技艺高过土师，大户人家动工时，都以请到风师为荣，又由于风师总是背着他的大麻袋，坊间便尊称其为“金麻袋”。风师赚得盆满钵满，已经成为王国的小富人家了。但土师仍旧是不慌不忙，细致地做着自己的事情。
王国几十年来风调雨顺，国库日渐丰裕。国王大喜，这日，国王决定扩建皇宫。百官向国王举荐了风师与土师。
国王请来两位工匠，命其各建筑一座凉亭，作为磨练。
风师扛来他的大麻袋，准备好建材后，风风火火开始建筑。10 号和砂石，15 号打桩……风师操作行云流水，但由于他的工具编号只有自己才熟习，其他人很少能帮上忙。国王看着风师的操作，逐渐皱起了眉头。
土师将其工具箱逐一打开，当他的工具都准备好时，风师已经开始打地基了。然后土师才开始建造凉亭。他指挥着建筑工用砂浆机稠浊砂浆，龙门架起吊……看着土师井井有条的指挥，国王眉头方才逐渐伸睁开，眼中露出赞许之色。
终极土师仍旧利用了三倍于风师的韶光方才完成凉亭的建造，但国王决定，任命土师为皇宫建造的御用工程师。
百官不解，只听国王说到：风师、土师的技艺巧夺天工，都是王国的能工巧匠。但风师干事随性，工具凌乱。皇宫扩建工程浩大，当职员逐渐增加，此法必乱。比较之下，风师只可偏居一隅，土师方可担此大任。
后来土师的表现恰好印证了国王的话，在土师的指挥下，皇宫的扩展只用了一年的韶光。新建的皇宫恢弘大气，安全可靠。百姓在震荡之余，方才想起：由土师经手的项目，无论大小，彷佛从未超过一年。风师虽以快有名，但卖力一个中等建筑时，常常会延期至两年旁边。卖力小型建筑尚可，当格局扩大后，土师才是最有“效率”的人。
故事的寓意很大略，工程质量与效率离不开好的建筑习气。当我们卖力一个小型项目时，我们追求速率，力求快速出成果，这时可以任性而为。当项目逐渐扩大，规范就会逐步显出它的主要性。
在软件开拓中也是一样，干净的地板能减少事件发生，归置到位的工具能提升生产力。软件质量，不但依赖于架构及项目管理，而且跟代码质量息息相关。代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期掩护、升级奠定了良好的根本。
破窗理论与童子军军规
犯罪生理学中有一个破窗理论，以一幢有少许破窗的建筑为例，如果那些窗不被及时修理好，可能会有毁坏者毁坏更多的窗户。终极他们乃至会闯入建筑内，如果创造无人居住，大概就在那里定居或者纵火。一壁墙，如果涌现一些涂鸦没有被洗濯掉，很快地，墙上就布满了乱七八糟、不堪入目的东西；一条人行道有些许纸屑，不久后就会有更多垃圾，终极人们会天经地义地将垃圾顺手丢弃在地上。
在编程中也常常涌现这样的问题，当我们接手一份混乱的代码后，如果不及时加以整理，终极将会导致代码越来越混乱。这是一种根本的代价谜题，之前的混乱与期限的压力让开发者连续制造混乱。当我们 review 代码时，听到最多的辩白便是：前一个人便是这么写的。事实上，问题的症结在于：他们没有花韶光让自己做得更快。
美国童子军有一条大略的军规：让营地比你来时更干净。
代码整洁之道
清理代码大概只是改好一个变量名，拆分一个有点过长的函数，肃清一点点重复代码，清理一个嵌套 if 语句。当梳理代码时，坚守此军规：每次 review 代码，让代码比你创造它时更整洁。
一、谨慎命名
给函数和变量取个好名字是精良程序员的基本功，取名的基本哀求是 名副实在，见文知意。如果名称须要注释来补充，那就不算是个好名字。
var d // 日期
修正为：
var date
取名的第二个哀求是 避免误导。比如数据本身不是一个 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，宁肯明确，毋为好玩。
二、函数和类
函数和类该当坚持 单一权责原则。保持高内聚，低耦合。隔离会让系统每个元素的理解变得随意马虎。
单一权责原则：在面向工具编程领域中，单一权责原则（Single responsibility principle）规定每个类都该当有一个单一的功能，并且该功能该当由这个类完备封装起来。一个类或者模块该当有且只有一个改变的缘故原由。
过长的函数会造成不易理解，如果某天这个函数须要修正的话，一个长长的函数会大大增加理解本钱。并且，小函数也能更好地复用。
如果一个函数做了多件事，一个明显的标志是无法为它起一个精准的名字。你会以为须要函数名须要利用 and 连接，比如 calculateAndPrintPrice，这时候最佳做法是将其拆分为 calculatePrice 和 printPrice 两个小函数。
函数的第二个规范是 只管即便不要在参数中通报状态值，状态值是函数做了多件事的明显标志。例如：
修正为：
函数的第三个规范是 同一个函数中的代码该当属于同一层级。良好的软件设计哀求分离位于不同层级的观点，较低层级观点和较高层级观点不应殽杂在一起。
修正为：
三、坏注释与好注释
注释并不是越多越好，有的注释纯属无意义的废话，例如：
这些注释看起来就像是喃喃自语，或许读者阅读这些注释的韶光比读代码还要长。
好的注释只该当用在必要时，用于警告其他程序员会涌现某种后果的注释是有用的，例如：
但，最好的注释是 没有注释，若代码足够有表达力，用代码来展示意图每每会更好。注释总是一种失落败。当我们无法找到不用注释就能表达自我的方法时，我们写了注释，这并不值得庆贺。由于注释常常会撒谎。缘故原由很大略：程序员不能坚持掩护注释，尤其是别人写的注释。当另一个人修正了代码后，每每不会去阅读上一个人写的注释，再修正注释。以是注释常常会与其所描述的代码分割开来，孑然飘零，越来越不准确。
写注释的常见动机之一是原有代码混乱。当我们阅读代码时，创造已有的代码令人困扰、乱七八糟。这时我们大概会见告自己：“等我阅读清楚后，给它写点注释！
”别那样做！
最好的做法是把代码整理干净。
修正为:
四、良好的格式
在我们阅读报纸时，在顶部，你期望有个头条，见告你故事的主题。然后第一段是全体故事的大纲，给出粗线条概述，但隐蔽了故事细节。接着读下去，细节渐次增加，直至你理解所有的细节。
代码的格式也要像新闻文章一样，最顶部给出高层次观点，向下渐次展开细节。函数该当紧跟调用处，担保垂直方向上的靠近。如果格式混乱，读者在阅读时总会滑上滑下，导致思维跳跃，增加不必要的理解难度。
影响格式的第二个要素是 缩进与间隔，当代化的 IDE 都有格式化代码快捷键，你也可以在设置中搜索"Reformat Code"，自定义格式化代码快捷键。随时格式化，并去掉多余的空行，让我们的代码保持清爽、整洁。
五、数据构造
在有的源代码中，作者采取长长的链式调用，乃至会鼓吹自己只写了一行代码便实现了此功能。事实上，绝不该当为了节省变量，写过长的链式调用，否则随意马虎造成"火车失落事"。精确的做法是遵守“得墨忒定律”：适当拆解链式调用，只和朋友发言，反面朋友的朋友发言，使得代码阅读和调试都更方便。
得墨忒定律（The Law of Demeter）：模块不应该理解它所操为难刁难象的内部环境。
修正为：
六、缺点处理
在处理程序非常时，我们常常会用到 try / catch 代码块，而 try / catch 代码块丑陋不堪，他们搅散了代码构造，把缺点处理与正常流程混为一谈。最好的做法是 把 try 和 catch 代码块的主体部分抽离出来，其余形成函数。缺点处理便是一件事。
当代化的措辞都有非常机制，非常情形如果不及时加以处理，可能会导致程序崩溃。以是有的程序员对付程序的非常情形会选择返回 0 或者 -1 等缺点码，以保持程序不崩溃。
别这样做，精确的做法是将缺点码更换为抛出非常，只有这样才能担保涌现缺点时立马就可以创造，而不是让程序在缺点的状态下连续实行，将来造成更加迷惑的缺点。
要谈论缺点处理，就一定要提及那些随意马虎引发缺点的做法。第一项便是返回 null 值。我不想去打算曾经见过多少险些每行代码都在检讨 null 值的运用程序。返回 null 值基本上便是在给自己增加事情量，也是在给调用者添乱。只要有一处没有检讨 null 值，运用程序就会失落控。返回 null 不如抛出 NullPointerException ，或是更换为一个 空工具。让调用者不再须要检讨 null，代码也就更整洁了。
总结
《代码整洁之道》是软件大师 Martin 的著作，英文名为《Clean Code》。本文作于笔者第二次阅读《代码整洁之道》后，本书讲述的大多是一些编程细节和好习气，并不是那种让人醍醐灌顶的书，它更像是一个指引，一本避坑指南，Martin 将其从业多年碰着的一些好习气和坏习气列举出来逐一比拟，见告读者哪些习气该当坚持，哪些习气该当摒弃。
比如笔者在阅读之前，确实受到一些流言影响，认为注释越多越好，越细越好。Martin 见告我，注释并不全然的好，程序员掩护程序的同时每每不会花韶光掩护注释，导致注释说谎；以及一些喃喃自语或抖机灵的注释实际上会影响代码的阅读。有的源代码中在大括号 ‘}’ 旁添加注释，表示它是哪一个条件的闭括号，在阅读本书之前，我可能认为这是一种好习气，乃至我可能会效仿，在阅读本书后我知道这也是一种冗余的代码，并不值得坚持。
Martin 在本书中见告我们精确的代码、好的代码该当若何若何，这样纵然我们在事情中，在公司缭乱不堪的源码中深陷泥塘，心中仍旧知道代码的伊甸园长什么样。有了这样一个清晰的目标，我们就能一步一步地向着它提高，而不至于走偏方向。或许这也是译者将其译作“道”的缘故原由吧。
最主要的是，Martin 向我们通报出自己“不向肮脏代码低头”，用他近乎偏执的决心清理代码、重构代码，担保它的整洁。阅读本书时，笔者心中充满了冲动与敬畏，真切地感想熏染到一位程序大师的工匠之心，我们要像照顾孩子一样照顾代码，像热爱生命一样热爱代码。
就像王国的两个工匠师一样平常，当我们做小项目时，我们可以化身风师，只用担保 逻辑通、能运行，但想要走得更远，我们就须要坚守土师的原则：保持好习气、不出错。起初是我们养成习气，后来是习气造就我们。
以上，便是笔者对《代码整洁之道》的阅读分享，也非常推举你花点韶光阅读这本书。在阅读本文后你有什么感想呢？欢迎在评论区留言分享～
本文作者：Alpinist Wang
声明：本文归 “力扣” 版权所有，如需转载请联系。文章封面图和正文中部分图片来源于网络，如有侵权联系删除。
