代码整洁之道
第一章
简洁的代码
1.能通过所有测试
2.没有重复代码
3.体现系统中的全部设计理念
4.包括尽量少的实体， 比如类，方法， 函数等
有意义的名称是体现表达力的一种方式， 消除重复和提高表达力有助于代码的整洁
对于涉及的模块进行相应的构建抽象封装
第二章 有意义的命名
2.2.选择体现本意的名称能让人更容易理解和修改代码
2.3 避免误导
应当避免使用与本意相悖的词，例如 hp, aix sco 都不应该作为变量名，因为它们是UNIX平台或类UNIX平台的专有名称
别用accountList来指称一组账号， 除非它真的是List 可以用accountGroup 或者bunchOfAccounts 甚至直接用accounts都会好一点
提防使用不同之处较小的名称
2.4做有意义的区分
废话是另一种没有意义的区分，假设你有一个product类。如果还有一个ProductInfo 或中ProductData类，它们名称虽然不同，意思却无区别。
2.5使用读得出来的名称
如果名称读不出来，讨论的时候就会显得尴尬
2.6使用可搜索的名称
名称长短应与其作用域大小相对应
2.7避免使用编码
2.8避免思维映射
不应当让读者在脑海中把你的名称翻译为他们熟知的名称
2.9类名
类名和对象名应该是名词或者名词短语
2.10方法名
方法名应当是动词或动词短语
2.12每个概念对应一个词
2.13别用双关语
2.14使用解决方案领域名称
2.15使用源自所涉及问题领域的名称
2.16添加有意义的语境
例如可以在与地址相关的变量时， 可以添加前缀addrFirstName addrLastName, addrState
第三章 函数
3.1短小
函数的第一规则是要短小
代码块和缩进 函数的缩进层级不该多于一层或两层
3.2只做一件事
函数应该做一件事，做好这件事，只做这件事
3.3每个函数一个抽象层级
自顶向下读店面，向下规则
3.4switch语句
switch语句天生要做N件事， 然而我们总无法避开switch语句，不过还是能够确保每个switch都埋葬在较低的抽象层级，而且永远不重复。 我们可以利用多态来实现这一点
3.5使用描述性的名称
好的名称可以较好的描述该函数所要做的事情
3.6函数参数
最理想的参数数量是零，其次是一个 再次是二。除非有足够特殊的理由才能用三个以上的参数
有三个参数的函数要比二元函数更难懂。 排序、琢磨、忽略的问题都会加倍提醒。 所以设置三元函数前一定要想清楚
针对三个及其以上的参数可以考虑进行封装
3.8分割指令与询问
函数要么做什么事，要么回答什么事，二者不应同时都做
如下代码，则会造成混乱
if (set(‘username’, ‘unclebob’))…
应改为如下代码
if (attributeExists(‘username’)) {
setAttribute(‘username’, ‘unclebob’ )
}
3.9使用异常代替返回错误码
3.10别重复自己
3.11 结构化编程
3.12 如何写出这样的函数
函数初级阶段可能会冗长而复杂，有太多缩进和嵌套循环，有过长的参数列表。
打磨这些代码，分解函数、修改名称、消除重复。
第四章注释
什么也比不上放置良好的注释来的有用。 什么也不会比乱七八糟的注释更有本身搞了一个模块。 什么也不会比陈旧、 提供错误信息的注释更有破坏性的
4.1注释不能美化糟糕代码
带有少量注释的整洁而有表达了的代码，要比带有大量注释的零碎而复杂的代码好得多。与其花时间编写解释你搞出的糟糕代码的注释，不让花时间清洁那堆糟糕的代码
4.2用代码来阐述
只要想上计谋中就能用代码来解释你的大部分意图。很多时候，简单到只需要创建一个描述与注释所言同一事物的函数即可
4.3好注释
4.3.1法律信息
例如版权及著作权声明
4.3.2 提供信息注释
例如注释解释某个方法的返回值
4.3.3对意图的解释
4.3.4阐述
有时注释把某些晦涩难懂的参数或返回值的意义翻译为某种可读形式。
4.3.5 警示
有时用于警告其他程序员会出现某种后果的注释也是有用的
4.4坏注释
4.4.1喃喃自语
4.4.2多余的注释
4.4.3误导性注释
4.4.4 循环式注释
所谓的每个函数每个变量都要有注释的规矩全然是愚蠢可笑的。这样只会让代码变得散乱，满口胡言。令人迷惑不解
4.4.5 日志式注释
4.4.6废话注释
注释废话连篇，读代码时 我们的眼光不会停留在它们上面。这类注释就变得毫无用处
4.4.8能用函数或者变量时就别用注释
4.4.49备注标记
4.4.11归属于署名
4.4.12注释掉的代码
直接把代码注释掉是讨厌的做法。
其他人不敢删除注释掉的代码，他们会想，代码依然放在那儿，一定有其原因， 而且这段代码很重要不能删除。
4.4.15信息过多
别再注释中加有趣的历史性话题或者无关的细节描述
4.4.16不明显的联系
注释及其描述的代码之间应该是显而易见。
第五章格式
你应该保持良好的代码格式，你应该选用一套管理代码格式的简单规则，然后贯彻这些规则
第五章格式
你应该保持良好的代码格式，你应该选用一套管理代码格式的简单规则，然后贯彻这些规则
5.2垂直格式
5.2.1向报纸学习
第一段是整个故事的大纲， 给出粗线条概述， 但隐藏了故事细节。 源文件也要像报纸文章那样， 名称应该简单且一目了然。 源文件最顶部应该给出高层次概念和算法
5.2.2概念间垂直方向上的区隔
几乎所以的代码都是从上向下读， 从左往右读。每行展示一个表达式或子句每组代码展示一条完整的思路。
这些思路用空白行隔开来。填加空白行可起到划分区块， 增强代码可读性。
5.2.3垂直方向上的靠近
如果说空白行隔开了概念， 靠近的代码则暗示里它们之间的紧密关系
5.2.4垂直距离
关系密切的概念应该相互靠近，应该避免迫使读者在源文件和类中跳来跳去
变量声明应尽可能靠近其使用位置
实体变量应该在类的顶部
相关函数：若某个函数调用了另外一个， 就应该把它们放到一起， 而且调用者应该尽可能放在被调用者上面
概念相关：概念相关的代码应该放到一起。 相关性越强， 彼此之间的距离就应该越短。 概念相关的函数通常拥有着共同的命名模式， 执行着同一基础任务的不同变种。例如数据类型的相关校验工作
5.3横向格式
一行代码应该有多宽？应尽可能保持代码行的短小
5.3.1水平方向上的区隔与靠近
我们使用空格字符将彼此紧密相关的事物链接在一起， 也用空格把相关性较弱的事物分开。
空格 空格 空格重要的事情说三遍
空格支付的另一种用法是强调其前面的运算符
5.3.2水平对齐
5.3.3缩进
团队规则
一组开发中应当认同同一种格式风格， 每一个成员都应该采用那种风格。
网友评论