王国的工匠师
风师有一个大麻袋，这是他的百宝箱，他所有的工具都在里面。他把锤子命名为 1 号，斧子命名为 2 号。这样他工作时，只需叫出简短的名字：1 号拿来固定，2 号拿来伐木……用完之后，将所有工具收回麻袋。风师总是背着麻袋来，背着麻袋去。不拘泥于形式，不管哪里都潇洒走一回。风师常说：这就是“效率”的秘诀。
风师每天总是业务繁忙，一个接一个的工程甚至排到了明年。百姓修房子，就图一个“快”字。相比之下，土师的生意就显得门可罗雀了。经常是在风师的活接不过来时，才有人请土师来帮忙建造。久而久之，人们已经默认风师的技艺高过土师，大户人家动工时，都以请到风师为荣，又因为风师总是背着他的大麻袋，坊间便尊称其为“金麻袋”。风师赚得盆满钵满，已经成为王国的小富人家了。但土师仍然是不慌不忙，细致地做着自己的工作。
国王请来两位工匠，命其各修建一座凉亭，作为考验。
土师将其工具箱一一打开，当他的工具都准备好时，风师已经开始打地基了。然后土师才开始建造凉亭。他指挥着建筑工用砂浆机混合砂浆，龙门架起吊……看着土师有条不紊的指挥，国王眉头方才渐渐舒展开，眼中露出赞许之色。
百官不解，只听国王说到：风师、土师的技艺巧夺天工，都是王国的能工巧匠。但风师做事随性，工具杂乱。皇宫扩建工程浩大，当人员逐渐增加，此法必乱。相比之下，风师只可偏居一隅，土师方可担此大任。
故事的寓意很简单，工程质量与效率离不开好的建筑习惯。当我们负责一个小型项目时，我们追求速度，力求快速出成果，这时可以率性而为。当项目逐渐扩大，规范就会逐步显出它的重要性。
破窗理论与童子军军规
在编程中也经常出现这样的问题，当我们接手一份混乱的代码后，如果不及时加以整理，最终将会导致代码越来越混乱。这是一种基础的价值谜题，之前的混乱与期限的压力让开发者继续制造混乱。当我们 review 代码时，听到最多的辩解就是：前一个人就是这么写的。事实上，问题的症结在于：他们没有花时间让自己做得更快。
代码整洁之道
一、谨慎命名
修改为：
var date修改为：
取名的第三个要求是 去掉冗余。Variable一词永远不应当出现在变量名中，Table一词永远不应当出现在表名中。nameString 会比 name 好吗？ProductInfo 、 ProductData 和 Product 有什么区别？更糟糕的是，如果代码中同时存在 Article 和 ArticleInfo 类，程序员怎么知道该调用哪个类呢？多个意义含混的冗余词汇只会让阅读者困惑，要区分名称，就要以读者能鉴别不同之处的方式来区分。
取名的第四个要求是：严谨，不要俏皮。笔者曾经接手一位外国同事写的代码，在一个类中，这位外国同事使用了 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 代码块的主体部分抽离出来，另外形成函数。错误处理就是一件事。
别这样做，正确的做法是将错误码替换为抛出异常，只有这样才能保证出现错误时立马就可以发现，而不是让程序在错误的状态下继续执行，将来造成更加迷惑的错误。
总结
比如笔者在阅读之前，确实受到一些流言影响，认为注释越多越好，越细越好。Martin 告诉我，注释并不全然的好，程序员维护程序的同时往往不会花时间维护注释，导致注释说谎；以及一些喃喃自语或抖机灵的注释实际上会影响代码的阅读。有的源代码中在大括号 ‘}’ 旁添加注释，表示它是哪一个条件的闭括号，在阅读本书之前，我可能认为这是一种好习惯，甚至我可能会效仿，在阅读本书后我知道这也是一种冗余的代码，并不值得坚持。
最重要的是，Martin 向我们传递出自己“不向肮脏代码低头”，用他近乎偏执的决心清理代码、重构代码，保证它的整洁。阅读本书时，笔者心中充满了感动与敬畏，真切地感受到一位程序大师的工匠之心，我们要像照顾孩子一样照顾代码，像热爱生命一样热爱代码。
以上，就是笔者对《代码整洁之道》的阅读分享，也非常推荐你花点时间阅读这本书。在阅读本文后你有什么感想呢？欢迎在评论区留言分享～
声明：本文归 “力扣” 版权所有，如需转载请联系。文章封面图和正文中部分图片来源于网络，如有侵权联系删除。
