代码整洁之道读书笔记ppt课件.ppt

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