代码整洁之道读书笔记PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与
ProctductData就是没有意义的区分，因为它们含义几乎一样。 c、使用读得出来的名字 d、使用搜索得出来的名字 e、接口和实现
Demo:IShapeFactory和SharpFactory之间，选择后者作为接口 名
18
函数
三、每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。
读者无法提纲挈领的代价是，它无法快速学习，快速理解。 从而为更多的bug埋下隐患。
19
函数
• 四、使用描述性名称
Demo:testtableHtmlSetupTeardownIncluder.rend er。
6
混乱代码的代价
随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。
这里的代码够简单了，但是没人知道 theList是什么东西、theList[0]的意思是什么、 d、是什么意义、以及返回list1该怎么用。
这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。 那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。
码寒码问码声来住
2
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
3
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
4
混乱代码的代价
一、要有代码
有人说过我们正在临近代码的终结点。快代码就会自动产生出 规约直接生成程序。
代码呈现了需求的细节。
5
如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧。
20
函数
五、函数参数 最好是0，其次是1，再次是2，避免3个及以上的参数个
数。 参数过多会使得客户程序员上手的代价加大，优秀代码的
可能性降低。
21
函数
五、抽离Try/Catch代码
将try/catch代码隔离出来，避免影响主程序逻辑。 Demo: Try{
13
命名
• 二、命名要避免误导
程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList 这 个 名 字 就 不 太 好 ， 因 为 list 这 词 在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。
14
命名
• 三、做有意义的区分
a、不要用数字命名， Demo:a1,a2,a3。
量少的实体，比如类、方法、函数等。
10
如何编写整洁代码
• 命名 • 函数 • 注释 •类
11
命名
一、要“名副其实” a、这件事情要严肃对待。 在起一个表意的名字上花时间是值得的，优秀程序员从细节 做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：int d;//消逝的时间，以天计算 应该使用指明计量对象和计量单位的名称。 Int elapsedTimeInDays; Int daysSinceCreation; Int daysSinceModificatin; Int fileAgeInDays’
混乱代码的代价
二、糟糕代码
你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验 的程序员，定然多次遇到过这类困境。我们有专用来形容这事的 词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏 的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们 到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。
7
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
8
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
• 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐 藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
• • 它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而
和提供清晰、尽量少的API 语言导致并非所有必需信息均可通过代码自身清晰表达。
9
整洁代码
• • 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的 • 能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽
15
函数
• 函数的第一条规则是要短小，第二条规则还是要短小。40
年的经验告诉作者，函数就是要短小。 • 20行封顶最佳。 • 每个函数都一目了然，每个函数都做一件事。而且每个函数
都依序把你带到下一个函数，这就是函数应该达到的短小程 度。
16
2019/9/13
17
函数
二、只做一件事
函数所做的事情都在一个抽象层级，叫“只做一件事”。 如果各个层级抽象混杂在一起，显然就做了Hale Waihona Puke Baidu止一件事了
读书交流会
多读书 好读书 读好书
1
献给广大不辞辛劳的程序员们
在在今垂
壮风就洛做夜一满
Bug
天但地天天死 白言松士萧说阳梦阑串园低举
天愿愿愿还病 发师下要萧我亲还卧代春头头
敲人意做没中改三敲问去兮在友在听码色敲望
代长敲比敲惊不千代童敲易敲如敲风飘关代明
码久代翼代坐完丈码子代水代相代雨出不码月
码鸟码起
12
命名
c、问题不在于代码的简洁度，而在于代码的“模糊度”。 这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java: pulic List<int[]> getThem(){ List<int[]> list1 = new ArrayList<int[]>(); For( int[] x: theList) If(x[0]==4) list1.add(x); return list1; }
ProctductData就是没有意义的区分，因为它们含义几乎一样。 c、使用读得出来的名字 d、使用搜索得出来的名字 e、接口和实现
Demo:IShapeFactory和SharpFactory之间，选择后者作为接口 名
18
函数
三、每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。
读者无法提纲挈领的代价是，它无法快速学习，快速理解。 从而为更多的bug埋下隐患。
19
函数
• 四、使用描述性名称
Demo:testtableHtmlSetupTeardownIncluder.rend er。
6
混乱代码的代价
随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。
这里的代码够简单了，但是没人知道 theList是什么东西、theList[0]的意思是什么、 d、是什么意义、以及返回list1该怎么用。
这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。 那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。
码寒码问码声来住
2
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
3
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
4
混乱代码的代价
一、要有代码
有人说过我们正在临近代码的终结点。快代码就会自动产生出 规约直接生成程序。
代码呈现了需求的细节。
5
如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧。
20
函数
五、函数参数 最好是0，其次是1，再次是2，避免3个及以上的参数个
数。 参数过多会使得客户程序员上手的代价加大，优秀代码的
可能性降低。
21
函数
五、抽离Try/Catch代码
将try/catch代码隔离出来，避免影响主程序逻辑。 Demo: Try{
13
命名
• 二、命名要避免误导
程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList 这 个 名 字 就 不 太 好 ， 因 为 list 这 词 在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。
14
命名
• 三、做有意义的区分
a、不要用数字命名， Demo:a1,a2,a3。
量少的实体，比如类、方法、函数等。
10
如何编写整洁代码
• 命名 • 函数 • 注释 •类
11
命名
一、要“名副其实” a、这件事情要严肃对待。 在起一个表意的名字上花时间是值得的，优秀程序员从细节 做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：int d;//消逝的时间，以天计算 应该使用指明计量对象和计量单位的名称。 Int elapsedTimeInDays; Int daysSinceCreation; Int daysSinceModificatin; Int fileAgeInDays’
混乱代码的代价
二、糟糕代码
你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验 的程序员，定然多次遇到过这类困境。我们有专用来形容这事的 词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏 的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们 到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。
7
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
8
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
• 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐 藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
• • 它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而
和提供清晰、尽量少的API 语言导致并非所有必需信息均可通过代码自身清晰表达。
9
整洁代码
• • 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的 • 能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽
15
函数
• 函数的第一条规则是要短小，第二条规则还是要短小。40
年的经验告诉作者，函数就是要短小。 • 20行封顶最佳。 • 每个函数都一目了然，每个函数都做一件事。而且每个函数
都依序把你带到下一个函数，这就是函数应该达到的短小程 度。
16
2019/9/13
17
函数
二、只做一件事
函数所做的事情都在一个抽象层级，叫“只做一件事”。 如果各个层级抽象混杂在一起，显然就做了Hale Waihona Puke Baidu止一件事了
读书交流会
多读书 好读书 读好书
1
献给广大不辞辛劳的程序员们
在在今垂
壮风就洛做夜一满
Bug
天但地天天死 白言松士萧说阳梦阑串园低举
天愿愿愿还病 发师下要萧我亲还卧代春头头
敲人意做没中改三敲问去兮在友在听码色敲望
代长敲比敲惊不千代童敲易敲如敲风飘关代明
码久代翼代坐完丈码子代水代相代雨出不码月
码鸟码起
12
命名
c、问题不在于代码的简洁度，而在于代码的“模糊度”。 这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java: pulic List<int[]> getThem(){ List<int[]> list1 = new ArrayList<int[]>(); For( int[] x: theList) If(x[0]==4) list1.add(x); return list1; }