《代码整洁之道读书笔记.》由会员分享，可在线阅读，更多相关《代码整洁之道读书笔记.（30页珍藏版）》请在金锄头文库上搜索。
1、读书交流会 多读书 好读书 读好书 举头望明月 低头敲代码 满园春色关不住 一串代码飘出来 夜阑卧听风雨声 做梦还在敲代码 洛阳亲友如相问 就说我在敲代码 风萧萧兮易水寒 壮士要去敲代码 松下问童子 言师敲代码 白发三千丈 Bug改不完 垂死病中惊坐起 今天还没敲代码 在天愿做比翼鸟 在地愿意敲代码 但愿人长久 天天敲代码 献给广大不辞辛劳的程序员们 阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员 主要内容 混乱代码的代价 整洁代码艺术、什么是整洁代码 如何编写整洁代码 混乱代码的代价 一、要有代码 有人说过我们正在临近代码的终结点。快代码就会自动产生出 来 不需要再人工编
2、写。程序员完全没用了 因为商务人士可以从 规约直接生成程序。 代码呈现了需求的细节。 混乱代码的代价 二、糟糕代码 你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验 的程序员，定然多次遇到过这类困境。我们有专用来形容这事的 词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏 的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们 到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码 。 混乱代码的代价 随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么
3、样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。 混乱代码的代价 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。 糟糕的代码可能毁掉一家公司。 混乱代码的代价是驱动生产力不断趋向零。 整洁不仅与效率有关，而且关于企业的生存。 什么样的代码是整洁代码？ 整洁代码 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。 整洁的代码简单直接。整洁的代码如同优美的散文。
4、整洁的代码从不隐 藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。 果断决绝。代码应当讲述事实 不引人猜测。它只该包含必需之物。 它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而 非多种做一件事的途径。它只有尽量少的依赖关系 而且要明确地定义 和提供清晰、尽量少的API。代码应通过其字面表达含义 因为不同的语 言导致并非所有必需信息均可通过代码自身清晰表达。 整洁代码 没有测试的代码不干净。不管它有多优雅 不管有多可读、多易理解 微乎测试 其不洁亦可知也。 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的 余地。代码作者什么都想到了 如果你企图改进它 总会
5、回到原点。 能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽 量少的实体，比如类、方法、函数等。 如何编写整洁代码 命名 函数 注释 类 命名 一、要“名副其实” a、这件事情要严肃对待。 在起一个表意的名字上花时间是值得的，优秀程序员从细节 做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：int d;/消逝的时间，以天计算 应该使用指明计量对象和计量单位的名称。 Int elapsedTimeInDays; Int daysSinceCreation; Int daysSinceModificatin; Int fileAgeInDays 命名 c、问题不
6、在于代码的简洁度，而在于代码的“模糊度”。 这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java: pulic List getThem() List list1 = new ArrayList(); For( int x: theList) If(x0=4) list1.add(x); return list1; 这里的代码够简单了，但是没人知道 theList是什么东西、theList0的意思是什么、 d、是什么意义、以及返回list1该怎么用。 这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。 那么怎么呢？应该根据这段代码
7、的意图来修改这里的函数名，变量名，值的含义（用常量） 。 命名 二、命名要避免误导 程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList这个名字就不太好，因为list这词在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。 命名 三、做有意义的区分 a、不要用数字命名， Demo:a1,a2,a3。 b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与 ProctductData就是没有意义的区分，因为它们含义几乎一样。 c、使用读得出来的名字 d、使用搜索得出来的名字 e、接口和实现
8、 Demo:IShapeFactory和SharpFactory之间，选择后者作为接口 名 函数 函数的第一条规则是要短小，第二条规则还是要短小。40 年的经验告诉作者，函数就是要短小。 20行封顶最佳。 每个函数都一目了然，每个函数都做一件事。而且每个函数 都依序把你带到下一个函数，这就是函数应该达到的短小程 度。 函数 二、只做一件事 函数所做的事情都在一个抽象层级，叫“只做一件事” 。如果各个层级抽象混杂在一起，显然就做了不止一件事了 函数 三、每个函数一个抽象层级 函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。 读者无法提纲挈领的代价是，它无法快速学习
9、，快速理解 。从而为更多的bug埋下隐患。 函数 四、使用描述性名称 Demo:testtableHtmlSetupTeardownIncluder.rend er。 如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧 。 函数 五、函数参数 最好是0，其次是1，再次是2，避免3个及以上的参数个 数。 参数过多会使得客户程序员上手的代价加大，优秀代码的 可能性降低。 函数 五、抽离Try/Catch代码 将try/catch代码隔离出来，避免影响主程序逻辑。 Demo: Try DeletePage(page);/DeletePage是一个方法 Catch(Exception e) LogEr
10、ror(e);/LogError是一个方法 错误处理就是一件事。 注释 什么也比不上放置良好的注释来的有用。什么也比不上乱七八糟的注释 更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破 坏性。 注释并不像辛德勒的名单。他们并不“纯然的好”。实际上，注释最 多也就是一个必须的恶，也编程语言足够有表达力，或者我们长于用这些 语言来表达意图，就不那么需要注释也许根本不需要。 注释 一、注释会撒谎。 a、这个比较令人费解。但是它真实的存在于我们的系统中 ， 并且是大量的存在。原因很简单，程序员不能坚持维持注释， 程序存在的时间越久，注释的可信度、可读程序就很低。作者 认为，程序员虽然有
11、保持注释精读的责任，但是更应该做的是 整理代码，减少注释，注释过多往往是一种程序“腐化的坏味 道”。 b、注释不能美化糟糕的代码。 注释 二、好的注释 a、不可省略的涉及到法律的信息 b、提供信息的注释:如果找不到好名字，则用注释提供信息是好的做法 c、对意图进行解释:对某些可以选择的实现决定进行解释 d、阐释:将一些晦涩难明的参数或者返回值的意义编译为更加可读的形式 e、警示:这里指的是一些特定行为的代码的注释。比如某个测试可能会运 行很长时间之类的注释。 f、TODO注释:未完成的列表。完成后要删除掉。 g、放大:放大、明示某些特殊用法的合理性。 注释 三、坏的注释 a、喃喃自语 这种情况
12、大量存在，属于程序员的只说自话，基本是 垃圾代码的借口或者错误决策的修正。 b、多余的注释 大量存在，没有什么意义的废话注释。 c、误导性注释 不够精确或者干脆写错了 d、循规试注释 指的是应文档化工具的需求就添加的本来不需要注释 的注释。 注释 e、日志试注释 指的是本代码文件的修改历史类，将每天的修改记录写上， 这完全没有必要，可以被现代源码管理工具取代。它影响了代码 阅读。 f、可怕的废话注释 g、能用函数或者变量的时候就不用注释 h、位域标记 这类注释用于标记一个特别的位置。这种用法应该在特定的 情况下使用，但是多数属于不必要的滥用。 i、括号后的注释 这里指的是代码太长了，在后添加注
13、释表示代码段结 束。这类注释一般是程序需要整理的标志。 注释 j、归属于署名 现在源码管理可以取代，基本不需要了。 k、注释掉的代码 L、HTML注释 令人讨厌。 m、非本地信息 n、信息过多 o、不明显的联系 类 一、类的组织 公共静态常量、私有静态变量、私有实体变量 、公共方法、私有工具函数。 类 二、类应该短小 对于函数，我们通过计算代码行数衡量大小。对于类，我们采用不同的 衡量方式，计算权责。 权责同职责，也同变化的原因。 1、类应该符合单一权责原则 2、类应该内聚 3、保持内聚会得到需要短小的类 关于类的组织这个话题比较大，比较原则性。注意理解不同设计原则之间 的因果依赖关系。 Thank You!
