代码整洁之道

目录 section 0 前言 Section 1 无用的碎碎念（请忽视） Section 2 函数原则 最重要的原则之一：函数必须短小 最重要的原则之二：只做一件事 原则三：每个函数一个抽象层级 原则四：switch语句怎么处理？ 原则五：使用描述性的名称 原则六：函数参数 6.1 一元函数的普遍形式 6.2 标识参数 6.3 二元函数 6.4 三元函数 6.5 参数对象 原则七：无副作用 原则八：分隔指令与询问 原则九：使用异常替代返回错误码 9.1 抽离try/catch代码块 9.2 错误处理就是一件事 原则十：别重复自己（DRY） 原则十一：结构化编程 Section 3 如何写出好的函数 section 0 前言 我是java工程师，所有的博客主要针对java代码，其他语言可参考，不尽相同。 最近在跟一个新的项目，属于新的产品线，时间紧任务重，但是我在这个产品线上做的第一个需求，提测就delay了两天，最后上线是delay更多，遇到了各种各样的问题，一些是因为自己的开发不规范，代码可读性可维护性不高。另一些问题是沟通不好，以及自己对原有的业务和要做的需求没有完全理解，等到做的时候才发现有好多坑是没有考虑到的。 所以愈发觉得，越是时间紧任务重的项目，越是要遵守开发规范，写出整洁代码显得格外重要。正好最近厂内也有培养代码规范的相关课程，也在某个app上看一个大佬写的专栏

1、软件系统应将启始过程和启始过程之后的运行时逻辑分离开，在启始过程中构建应用对象，也会存在互相缠结的依赖关系。 2、将构造与使用分开的方法之一是将全部构造过程搬迁到一个专门的模块中，设计系统的其余部分时，假设所有对象都已正确构造和设置。 3、有时应用程序也要负责确定何时创建对象，在这种情况下，可以使用抽象工厂模式让应用自行控制何时创建对象。 4、在依赖管理情景中，对象不应负责实体化对自身的依赖。可使用依赖注入解决。 5、“一开始就做对系统”纯属神话。反之，我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。 6、在代码层面与架构关注面分离开。 7、没必要先做大设计（Big Design Up Front, BDUF）。实际上，BDUF甚至是有害的，它阻碍改进，因为心理上会抵制丢弃既成之事，也因为架构上的方案选择影响到后续的设计思路。 8、模块化和关注面切分成就了分散化管理和决策。 9、明智使用添加了可论证价值的标准。创立标准的过程有时漫长到行业等不及的程度，有些标准没能与它要服务的采用者的真实需求相结合。 10、系统需要领域特定语言（Domain-Specific Language, DSL）。 p.s. 这一章的术语有点多，快速浏览一遍看得我有点懵，以后有空再重新看一下这章吧。 来源： https://www.cnblogs.com/winsons/p

1. 以下全部条款源于·<Clean Code Robert.C.Martin>Chapter 17，这里对其进行文字层面的加工，简化，便于以后能短时浏览 2. 出于1.的原因，部分条款不解释为什么，就这么做 3. 少数和我的编程哲学或者代码美学有悖的条款没有保留 4. 事无绝对，编程不需要权威，如果有一个令人令己信服的理由去违反条款请放手去做 5. 向前辈致敬 注释 C1：不恰当的信息 注释只应该描述和代码有关的技术性信息，作者、修改记录、修改时间等信息应该保存在源码控制系统。 C2：废弃的注释 过时、无关、不正确的注释就是废弃的注释，最好尽快更新或者删除。废弃的注释会远离它们曾经描述的代码。 C3：冗余注释 代码能充分self-explaining，那么注释就是多余的，例如：i++; //increment i C4：糟糕的注释 如果要写注释就要确保字斟句酌写出最好的注释，别瞎扯别画蛇添足，保持简洁。 C5：注释掉的代码 删除它。 环境 E1：需要多步才能实现构建 构建系统应该是单步的小操作，不应该一点一点从源码控制系统签出。 E2：需要多步才能做到的测试 使用单个指令就应该能运行全部单元测试。 函数 F1：过多参数 函数参数尽量<=3。 F2：输出参数 别这么做，考虑修改他所在对象的状态（输出参数指传入参数，函数对它进行操作，然后后续操作使用这个参数） F4：死函数

1、TDD（测试驱动开发，Test Drive Development）三定律： 　　定律一、在编写不能通过的单元测试前，不可编写生产代码。 　　定律二、只可编写刚好无法通过的单元测试，不能编译也算不过。 　　定律三、只可编写刚好足以通过当前失败测试的生产代码。 2、测试代码和生产代码一样重要。 3、测试能让你对设计和架构的改动没有顾虑。 4、整洁的测试最重要的要素：可读性。它应该和其他代码一样：明确，简洁，还有足够的表达力。 5、在测试环境中，可以为了整洁的代码舍弃部分性能，因为测试代码不会在外界中使用，只供测试用。这就是生产环境和测试环境的双重标准。 6、单个测试中的断言数量应该最小化。 7、每个测试只测试一个概念。不应该一个测试函数测试多个不同的事。 8、整洁的测试还遵循以下五条原则： 快速 独立 可重复 自足验证 及时 来源： https://www.cnblogs.com/winsons/p/12402391.html

书籍信息 书名：《代码整洁之道》 原作名：Clean Code: A Handbook of Agile Software Craftsmanship 作者： [美] Robert C·Martin 豆瓣评分：8.6分(1614人评价) 内容简介 软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。 本书提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，本书作者给出了一系列行之有效的整洁代码操作实践。这些实践在本书中体现为一条条规则（或称“启示”），并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。 本书阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。 作者简介 Rober C．Martin，Object Mentor公司总裁。面向对象设计、模式、UML、敏捷方法学和极限编程领域的资深顾问。他是Designing Object-Oriented C++Applications Using the BoochMethod以及Jolt获奖图书Agile

1. 要有代码 代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近 的语言。我们可以创造帮助把需求解析和汇整为正式结构的各种工具。然而，我们永远无法抛弃必要的精确性——所以代码永存。 勒布朗（LeBlanc）法 则：稍后等于永不（Later equals never）。 沼泽（wading）：糟糕的代码，对代码的每次修改都影响到其他两三处代 码。 2.2 名副其实 变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存 在，它做什么事，应该怎么用。 如果名称需要注释来补充，那就不算是名副其实。 int d; // 消逝的时间，以日计 名称d什么也没说明。它没有引起对时间消逝的感觉，更别说以日计了。我们应该选 择指明了计量对象和计量单位的名称： int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; 2.3 避免误导 别用accountList来指称一组账号，除非它真的是List类型。 List一词对程序员有特殊意 义。如果包纳账号的容器并非真是个List，就会引起错误的判断。 所以，用 accountGroup或bunchOfAccounts，甚至直接用accounts都会好一些。 误导性名称真正可怕的例子，是用小写字母

本周我开始阅读Robert C. Martin所著的《代码整洁之道》一书，希望能从中收获高效编写代码的诀窍，因为我自认为我的代码有时候比较糟糕，不太容易维护。一方面，是我没有养成良好的编程习惯；另一方面，我不太清楚什么才是真正整洁的代码。下面是我本周阅读的心得，与大家分享一下，希望能给志同道合的人以启迪。 糟糕的代码 本书中介绍了20世纪80年代末的一个公司倒闭的原因，起初，那家公司写出了一个很流行的杀手应用，以至于许多专业人士都前去购买，但是，就因为他们急着推出产品，而把代码写得乱七八糟，最后再也没办法管理他们的代码，用户数量也就日益减少，最后这家公司就关门大吉了。 看完了这个故事，我产生了深深的恐惧感，代码写得糟糕竟然会产生这么严重的后果，回想自己原来编程时的恶习，我就倒吸一口冷气。我记得在刚刚开始学编程时，老师曾经告诉我们初学者就要尽量给自己的代码写注释，这样写出来的代码的可读性比较高，而且在代码出bug时，可以较为方便的找到bug的所在。但是，我觉得写注释太麻烦了，所以经常省略这一环节，结果就是当代码出问题时，我就只能从头开始找bug，投入大量的时间才能真正解决问题。更严重的是，我一旦长时间没有接触自己的代码，就会遗忘自己的思路，以至于看不懂自己的代码...... 想到这里，我决定以后要努力改掉这一个坏毛病，否则虽然在写代码时虽然可以节省较多的时间，但是代码一旦出了问题

一、函数 1.短小 函数的第一规则是要短小，第二规则还是要短小；函数应该在20行封顶，每个函数只做一件很明确的小事，每个函数都依序将逻辑带入下一个函数； 2.只做一件事 函数应该只做一件事，做好这件事，只做这一件事； 只做一件事是保障函数短小原则的基础；那么问题来了，我们 如何判断函数是否只做了一件事 呢？最重要的一个判断方式就是，函数是否只是做了统一抽象层上的步骤，因为一个功能的实现一定会有较多的抽象层，而每一个抽象层都只有简单的几件事，就如同一个树结构，每一个父节点对应的子节点的数量其实都是比较少的（这里父节点相当于高层调用，它所对应的所有子节点为同一抽象层），其实也就是每一个抽象高层的下一底层都不会太多，所以我们只要能保证函数里的代码做的都是同一抽象层上的事情，就基本可以判定这个函数只做了一件事； 另一个判断方法：试着能不能将该函数再拆分出一个函数，该函数不仅仅是单纯阐述其实现； 3.每个函数一个抽象层级 正如，上文所提到的，要确保函数只做一件事，函数中的语句都要在同一抽象级别上； 自顶向下读代码：向下规则，我们希望代码拥有自顶向下的阅读顺序，我们希望每一个函数都可以进入到下一抽象层级的函数，这就是向下规则； 也就是上述“树”的思想类似，每一个函数都相当于一个节点，然而这个节点中也指向了所有的孩子节点；每个函数内封装的都是在同一级的函数节点

1. 为什么要并发 　　a) 并发是一种解耦策略。他帮助我们吧做什么（目的）和何时做（时机）分解开。 　　b) 在web应用的servlet模式下，当有web请求时，servlet就会异步执行。 2. 挑战 　　a) 当两个线程相互影响时就会出现不可预期的情况。这是因为线程在执行那行java代码时有许多可能路径可行，有些路径会产生错误的结果。回答这个问题需要理解 Just-IN-Time编译器如何对待生成的字节码，还 　　要理解java内存模型认为什么东西具有原子性 3. 并发防御原则 　　a) SRP 　　　　i. 并发相关的代码有自己的开发，修改和调优生命周期 　　　　ii. 开发相关代码有自己要对付的挑战，和非并发代码不同 　　　　iii. 即便没有周边应用程序增加的负担，写的不好的并发代码可能的出错方式数量也足够挑战性 　　　　iv. 建议：分离并发代码和其他代码 　　b) 推论：限制数据作用域 　　　　i. 谨记数据封装；严格限制对可能被共享的数据的访问 　　c) 推论：使用数据复本 　　　　i. 从一开始就避免共享数据，从多线程收集所有副本的结果，并在单个线程中合并这些结果 　　d) 推论：线程应尽可能地独立 　　　　i. 尝试将数据分解到可被独立线程（可能在不同处理器上）操作的独立子集 4. 了解java库 　　a) 线程安全群集 5. 了解执行模型 　　a) 　　

迭进 1、通过迭进设计达到整洁目的 运行所有测试 不可重复 表达了程序员的意图 尽可能的减少类和方法的数量 以上规则按照其重要程度排序 递增式的重构代码，测试消除了对清理代码就会破坏代码的恐惧 尽可能少的类和方法 并发编程 关于并发编程的中肯说法 并发会在性能和额外代码上增加一些开销 正确的并发是复杂的，即便对于简单的问题也是如此 并发缺陷并非总能，所以总被看做偶发事件而忽略，未被当作真的缺陷看待 并发常常需要对设计策略的根本性修改 并发防御的原则 a、单一职责原则 并发相关的代码有自己的开发、修改和调优的生命周期 并发相关的代码有自己要对付的挑战，和非并发相关代码不同 而且更难 即使没有周边应用程序的负担，写的不好的并发代码可能出错方式的数量也很大 建议：分离并发相关代码和其他代码 b、推论 限制数据的作用域 c、推论：使用数据副本 避免共享数据的好方法之一就是一开始就避免共享数据，某种方式下可能复制对象并以只读方式对待，再另外的情况下，可能复制对象，对多个线程中的复本进行收集，并在单个线程中合并这些结果。 d、推论：线程应该尽可能的独立 建议：尝试将数据分解到可能独立的线程操作的独立子类 e、线程执行模型 生产者-消费者模型 读者-作者模型 宴席哲学家 哲学家就餐问题 f、警惕同步方法之间的依赖 g、保持同步区域微小 测试线程代码的建议 a、将伪失败看作可能的线程问题