关于程式码整洁的总结和笔记

前言

《程式码整洁之道》在业内有很高的知名度，被诸多前辈推荐给后来者阅读。本书以循序渐进改造一个小程式的方式，演示了一个程式可能的各种设计（在程式码层面）。手把手教你该怎么设计程式码，为何要这样设计，这样设计的好处是什么。通过一周的阅读，总结了如下要点。

一 函式

所有的程式设计都是从HellWorld这个小函式开始的，学会设计函式非常重要

函式要短。短才方便阅读、维护和设计。(每个人都经历过读不懂自己程式码的尴尬)函式只做一件事。依照单一职责原则设计函式。一个函式可以:流程控制，逻辑判断，改变变数状态，以及做运算，或者呼叫多个下一抽象级的函式。函式分解成多个抽象层级设计，高层函式只调用下次层函式，呈树状图，层层封装。函式不应该有标识引数(除了作为API的函式)，这意味着函式有至少两种执行方式，违反了第2条原则。而且明显能拆成多个小函式。函式引数越少越好有，多个引数应该封装成一个整体传入的。如果逻辑上不是一个整体，则函式肯定能被拆成多个小函式然后被分别呼叫。第4条标识引数可以封装进整体传入函式，而不是直接作为函式的引数函式真的最好只做一件事，不要为了一时方便顺手加几行程式码。如登入验证时，函式用来验证username和password，在验证之后顺便给使用者初始化些其他东西。会导致这个函式在其他时候无法验证使用者资讯。底层函式不应该改变引数状态，如果想改变某类的状态，就把该函式加入该类，让它自己呼叫函式。如：把改变类x的状态的函式呼叫addFooter(x)，改为x.addFooter()。函式不要返回错误码，这需要你有错误码的列举类，并且违反了开放封闭原则（你需要加入新错误码来扩充套件新错误），直接丢掷异常就好了。（可以通过继承父异常来扩充套件）。但是实际上错误码的应用不比异常少，而且异常也会导致程式码的臃肿。函式名称应该描述清楚函式作用，避免频繁去看文件，这对于短小的函式来说不难办到，如果很难命名可能需要思考函式是否有依照以上原则设计(你一个函式可能做了很多事情)。并且名称的命名应该不容易与其他函式名称形成混淆。如：add()在calculator中意思是加，而在List中就不应该用add表示插入集合了，应该用insert或append。简单来说就是一个概念对应一个词，并且始终如一。二 格式

每个人都有自己的编码风格，书中总结了一些Java及其他语言的建议

好的格式应该由小且精的程式码片段（函式）组成封包程式码，导包程式码，成员变数，函式方法。都用空行隔开，形成分开的程式码块函式按呼叫顺序从上到下排列，类变数在顶端宣告，方法变数在使用前宣告一行程式码不超过100个,同一行的计算可以按先后顺序用空格隔开，如：100 * 732 / (2+3) * (5-1)小括号内的运算全都挤在了一起，其他运算都有空格隔开，很容易看出运算顺序缩排代表了一种包含关系。Java没有强制要求，但是python就是用缩排表示包含。说了这么多最后总结道：老大规定用啥格式就用啥格式三 注释

其实注释写了后，看的最多的还是自己

好程式码只需要少量注释，程式码就能表达意图——回到之前的内容，这要求我们写小且精的函式。（但这不是你不写注释的理由）好的注释应该是这样的。如：对抽象意图或者深远意义的解释（如我这个函式为啥用这个方法实现）；阐述长且难读的函式（这种难读不是因为程式码写得烂，而是业务逻辑复杂）；警示一些关键重要的部分（这些部分一般是函式会改变某些资料实体）；TODO注释提醒并告知未来要做的事；学着公共API的JAVADOC写就是好注释（虽然也有少数烂注释）；烂的注释往往是这样的。如：多余的注释（简单函式强行加上注释，读源代码会比注释更快）；误导的注释（注释本来就是错的，可能源自你更新了程式码没更新注释——小函式特别可能出现这个问题）；注释掉的程式码（你为何不删了程式码？）；废话太多的注释（语文是体育老师教的）。四 类

书中对于函式的设计其实和类的设计思想是类似的，所以类应该功能单一且小巧，越小耦合性越低，最后用门面模式组合起来向外提供API就好了

五 系统

系统整体结构的设计

把系统的整体构造和业务使用分开。不要让构造影响使用，也不要让程式的执行反过来影响构造。这也是Spring这么应用广泛的原因之一，Spring Core就是个类容器。把业务逻辑和检查或日志方案分离，不然纠缠在一起的程式码会很难看懂和修改。Spring AOP也解决了这个问题。六 测试

测试不仅仅是测试小姐姐的事情

测试函式（方法）也应该短小（如果函式原本够小的话测试函式自然会小）每个类最好都测试下，测试时间会比以后debug时间少。从底层函式一点点测上去，以后debug能迅速定位。测试类应该储存下来，方便每次修改后进行测试