代码整洁之道.doc

即便是在宏伟的建筑作品中，我们也听到关注细节的回响。认真对待每个变量名，你当用为自己第一个孩子命名般的谨慎来给变量命名。
全新倾注于细节，屡见于追求卓越的行为之中。
小处要诚实。
是否已尽力“把露营地清理得比来时还干净”？签入代码前是否已做重构？
是的，我们就是一群代码猴子，上蹿下跳，自以为领略了编程的真谛。可惜，当我们抓着几个酸桃子，得意洋洋坐到树枝上，却对自己造成的混论熟视无睹。那堆“可以运行”的乱麻程序，就在我们眼皮底下慢慢腐坏。
稍后等于永不（Later equals never）。
制造混乱无助于赶上期限。混乱只会立刻拖慢你，叫你错过期限。赶上期限的唯一方法——做得快的唯一方法——就是始终可能保持代码整洁。
整洁的代码只做一件事。
代码应当讲述事实，不引人猜测。
如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专门为解决那个问题而存在，就可以称之为漂亮的代码。
有意义的命名：
变量、函数或类的名称应该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。
程序员必须避免留下掩藏代码本意的错误线索，应当避免使用与本意相悖的词。
以同样的方式拼写出同样的概念才是信息，拼写前后不一致就是误导。
要区分名称，就要以读者能鉴别不同之处的方式来区分。
使用可搜索的名称：长名称胜于短名称，搜得到的名称胜于用自造编码写就的名称，名称长短应与其作用域大小相对应。
不必用前缀来标明成员变量。
专业的程序员了解，明确是王道，专业程序员善用其能，编写其他人能理解的代码。
类名和对象名应该是名词或名词短语。
方法名应当是动词或动词短语。
函数名称应当独一无二，而且要保持一致，即同样的目的以同样的命名称呼。
别用双关语，即不要同一术语用于不同概念。
只有程序员才会读你的代码，所以，尽管用那些计算机科学术语、算法名、模式名、数学术语吧。依据问题所涉领域来命名可不算是聪明的做法。
很少有名称是能自我说明的——多数不能。你需要用有良好命名的类、函数或名称空间来放置名称，给读者提供语境如果没这么做，给名称添加前缀就是最后一招了。
~即使是需要获得一个字符串常量也可以用一个函数去获取，这就是干净利落。
只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境。名称精确正是命名的要点。
取好名字最难的地方在于需要良好的描述技巧和共有文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。

函数：
函数的第一规则是要短小，第二规是还要更短小。函数也不该有100行那么长，20行封底最佳。
If语句、else语句、while语句等，其中的代码块应该只有一行。块内调用的函数拥有较具说明性的名称。这也意味着函数不应该大到足以容纳嵌套结构，函数的缩进层级不该多于一层或两层。
函数应该做一件事。做好这件事。只做这一件事。要判断函数是否不止做了一件事，还有一个方法，就是看是否能再拆出一个函数，该函数不仅只是单纯的重新诠释其实现。
要确保函数只做一件事，函数中的语句都要在同一抽象层级上。处于同一抽象级别可保持函数短小、确保函数只做一件事。
自顶向下读代码：向下规则：我们想要让代码拥有自顶向下的阅读顺序。我们想要让每个函数后面都跟着位于下一抽象层级的函数。
长而具有描述性的名称，要比短而令人费解的名称好。长而具有描述性的名称，要比描述性的长注释好。
参数与函数名处在不同的抽象级，它要求你了解目前并不特别重要的细节。
标识参数丑陋不堪。向函数传入布尔值就是宣布本函数不止做一件事，如果标识为true将会这样做，标志为false则会那样做。
如果参数看来需要两个、三个或三个以上参数，就说明其中一些参数应该封装为类了。（这说明其中某些参数有联系，应该封装到一块去）
普遍而言，应避免使用输出参数，如果函数必须要修改某种状态，就修改所属对象的状态吧。
分隔指令与询问。
使用异常替代返回错误码，当返回错误码时，就是在要求调用者立刻处理错误。
最好把try和catch代码块的主题部分抽离出来，另外形成函数。
使用异常替代错误码，新异常就可以从异常类派生出来。

注释：
如果你发现自己需要写注释，再想想看是否能用代码来表达。注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误。原因很简单那，程序员不能坚持维护注释。
代码在变动，在演化。从这里移到哪里。彼此分离、重造又合到一起。注释并不总是随之变动。注释常常会与其所描述的代码分隔开来，孑然飘零，越来越不准确。
真实只在一处地方：代码。只有代码能忠实地告诉你它做的事。那是唯一真正准确的信息来源。所以，尽管有时也需要注释，我们也该多花心思尽量减少注释量。
注释不能美化糟糕的代码，如果代码烂不是应当写注释而是把代码搞干净。带有少量注释的整洁而有表达力的代码，要比带有大量注释的零碎的而复杂的代码像样得多。
能用函数或变量时就别用注释。
注释的作用是解释未能自行解释的代码。
短函数不需要太多描述。为只做一件事的短函数选个好名字，通常要比写函数头注释要好。
关系密切的概念应该互相靠近。
一般而言，我们想自上向下展示函数条用依赖顺序，被调用的函数应该放在执行调用的函数下面。像报纸文章一般，我们指望最重要的概念先出来，指望以包括最少细节的方式表述它们。我们指望底层细节最后出来，这样，我们就能扫过源代码文件，自最前面的几个函数获知要职，而不至于沉溺到细节中。

对象和数据结构
隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象。类并不简单的用取值器和赋值器将其变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。
模块不应了解它所操作对象的内部情形。类C的方法f只应该调用以下对象的方法：
·C
·由f创建的对象
·作为参数传递给f的对象
·由C的实体变量持有的对象

类
类应该短小，即计算权责要尽可能小。
类的名称应该描述其权责。（个人觉得不同抽象程度或者层次的东西应该分开）
如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越有可能拥有过多权责。
单一权责原则（SRP）认为，类或模块应有且只有一条加以修改的理由。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的行为。
如果有函数想要共享某些变了，为什么不让它们拥有自己的类呢？当类丧失了内聚性，就拆分它。
分离函数的时候也就是可以分离类的时候，因为类本身就是对函数和变量的封装。
依赖倒置原则：类应当依赖于抽象而不是依赖于细节。
要想创建整洁的系统，需要有消除重复的意愿，即便对于短短几行也是如此。
写出自己能理解的代码很容易，因为在写这些代码时，我们正深入要解决的问题。代码的其他维护者不会那么深入，也就不易理解代码。
短小的类和函数易于命名，易于编写，易于理解。
做到写出的代码有表达力的最重要的方式是尝试，有太多时候，我们写出能工作的代码就转移到下一个问题上，没有下足功夫调整代码，让后来者易于阅读。记住，下一位读代码的人最有可能是你自己。所以，多少尊重一下你的手艺吧。花一点点时间在每个函数和类上。选用较好的名称，将大函数切分为小函数，时时照顾自己创建的东西。用心是最珍贵的资源。
不要将系统错误归咎于偶发时间。
用多态替代if/esle或switch/case。