程序员代码课程（优秀程序员需要掌握的）

​在一个古老的王国里，有两个建筑工匠——风师与土师。就实操经验而言，他们的技艺相差无几。差别在于，风师以“效率”闻名，若你要修一栋房子，找他仅需一月时间便可完成；土师以“稳定”闻名，他总是将东西归置整齐后，方才破土动工，风师只需一月完成的工程，土师需要三个月。

风师有一个大麻袋，这是他的百宝箱，他所有的工具都在里面。他把锤子命名为 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

声明：本文归 “力扣” 版权所有，如需转载请联系。文章封面图和正文中部分图片来源于网络，如有侵权联系删除。

,