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

读书交流会

多读书

好读书

读好书 读书交流会

多读书

好读书

读好书举头望明月低头敲代码满园春色关不住一串代码飘出来夜阑卧听风雨声做梦还在敲代码洛阳亲友如相问就说我在敲代码风萧萧兮易水寒壮士要去敲代码松下问童子言师敲代码白发三千丈Bug改不完垂死病中惊坐起今天还没敲代码在天愿做比翼鸟在地愿意敲代码但愿人长久天天敲代码献给广大不辞辛劳的程序员们举头望明月献给广大不辞辛劳的程序员们阅读本书有两种原因第一，你是个程序员第二，你想成为更好的程序员阅读本书有两种原因主要内容混乱代码的代价整洁代码艺术、什么是整洁代码如何编写整洁代码主要内容混乱代码的代价混乱代码的代价YourTextHereYourTextHere一、要有代码

有人说过我们正在临近代码的终结点。快代码就会自动产生出来不需要再人工编写。程序员完全没用了因为商务人士可以从规约直接生成程序。

代码呈现了需求的细节。混乱代码的代价YourTextHereYourText混乱代码的代价二、糟糕代码

你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验的程序员，定然多次遇到过这类困境。我们有专用来形容这事的词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。混乱代码的代价二、糟糕代码混乱代码的代价随着混乱的增加，团队生产力也持续下降趋向于零。当生产力下降时，管理层就只有一件事可做了，增加更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们制造更多的混乱，驱动生产力向零那端不断下降。混乱代码的代价随着混乱的增加，团队生产力也持续下混乱代码的代价将需求明确到机器可以执行的程度，就是编程要做的事，这种规约就是代码。糟糕的代码可能毁掉一家公司。混乱代码的代价是驱动生产力不断趋向零。整洁不仅与效率有关，而且关于企业的生存。

什么样的代码是整洁代码？混乱代码的代价将需求明确到机器可以执行的程度，就是编程要做的整洁代码代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引诱别人做没规矩的优。整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。果断决绝。代码应当讲述事实不引人猜测。它只该包含必需之物。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系而且要明确地定义和提供清晰、尽量少的API。代码应通过其字面表达含义因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。整洁代码代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关整洁代码没有测试的代码不干净。不管它有多优雅不管有多可读、多易理解微乎测试其不洁亦可知也。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了如果你企图改进它总会回到原点。能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等。整洁代码没有测试的代码不干净。不管它有多优雅不管有多可读、如何编写整洁代码命名函数注释类如何编写整洁代码命名命名一、要“名副其实” a、这件事情要严肃对待。

在起一个表意的名字上花时间是值得的，优秀程序员从细节做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：intd;//消逝的时间，以天计算

应该使用指明计量对象和计量单位的名称。 IntelapsedTimeInDays; IntdaysSinceCreation; IntdaysSinceModificatin; IntfileAgeInDays’命名一、要“名副其实”命名c、问题不在于代码的简洁度，而在于代码的“模糊度”。

这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java:pulicList<int[]>getThem(){ List<int[]>list1=newArrayList<int[]>(); For(int[]x:theList) If(x[0]==4) list1.add(x); returnlist1; }

这里的代码够简单了，但是没人知道theList是什么东西、theList[0]的意思是什么、d、是什么意义、以及返回list1该怎么用。

这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。命名c、问题不在于代码的简洁度，而在于代码的“模糊度”。命名二、命名要避免误导

程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList这个名字就不太好，因为list这词在java中是一个类型，如果这个名字表达的类型或者含义不是list就不应该这样命名。命名二、命名要避免误导命名三、做有意义的区分

a、不要用数字命名， Demo:a1,a2,a3。b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与ProctductData就是没有意义的区分，因为它们含义几乎一样。c、使用读得出来的名字d、使用搜索得出来的名字e、接口和实现 Demo:IShapeFactory和SharpFactory之间，选择后者作为接口名命名三、做有意义的区分函数

函数的第一条规则是要短小，第二条规则还是要短小。40年的经验告诉作者，函数就是要短小。20行封顶最佳。每个函数都一目了然，每个函数都做一件事。而且每个函数都依序把你带到下一个函数，这就是函数应该达到的短小程度。函数函数的第一条规则是要短小，第二条规则还是要短小。40年函数二、只做一件事

函数所做的事情都在一个抽象层级，叫“只做一件事”。如果各个层级抽象混杂在一起，显然就做了不止一件事了函数二、只做一件事函数三、每个函数一个抽象层级函数中混杂不同的抽象层级，往往让人迷惑。读者无法判断哪些是基础概念哪些是细节。读者无法提纲挈领的代价是，它无法快速学习，快速理解。从而为更多的bug埋下隐患。函数三、每个函数一个抽象层级函数四、使用描述性名称Demo:testtableHtmlSetupTeardownIncluder.render。如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧。函数四、使用描述性名称函数五、函数参数最好是0，其次是1，再次是2，避免3个及以上的参数个数。参数过多会使得客户程序员上手的代价加大，优秀代码的可能性降低。函数五、函数参数函数五、抽离Try/Catch代码将try/catch代码隔离出来，避免影响主程序逻辑。Demo:Try{ DeletePage(page);//DeletePage是一个方法}Catch(Exceptione){LogError(e);//LogError是一个方法}

错误处理就是一件事。函数五、抽离Try/Catch代码注释什么也比不上放置良好的注释来的有用。什么也比不上乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。注释并不像辛德勒的名单。他们并不“纯然的好”。实际上，注释最多也就是一个必须的恶，也编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释——也许根本不需要。注释什么也比不上放置良好的注释来的有用。什么也比不注释一、注释会撒谎。a、这个比较令人费解。但是它真实的存在于我们的系统中，并且是大量的存在。原因很简单，程序员不能坚持维持注释，程序存在的时间越久，注释的可信度、可读程序就很低。作者认为，程序员虽然有保持注释精读的责任，但是更应该做的是整理代码，减少注释，注释过多往往是一种程序“腐化的坏味道”。b、注释不能美化糟糕的代码。注释一、注释会撒谎。注释二、好的注释a、不可省略的涉及到法律的信息b、提供信息的注释:如果找不到好名字，则用注释提供信息是好的做法c、对意图进行解释:对某些可以选择的实现决定进行解释d、阐释:将一些晦涩难明的参数或者返回值的意义编译为更加可读的形式e、警示:这里指的是一些特定行为的代码的注释。比如某个测试可能会运行很长时间之类的注释。f、TODO注释:未完成的列表。完成后要删除掉。g、放大:放大、明示某些特殊用法的合理性。注释二、好的注释注释三、坏的注释a、喃喃自语

这种情况大量存在，属于程序员的只说自话，基本是垃圾代码的借口或者错误决策的修正。b、多余的注释

大量存在，没有什么意义的废话注释。c、误导性注释

不够精确或者干脆写错了d、循规试注释

指的是应文档化工具的需求就添加的本来不需要注释的注释。注释三、坏的注释注释e、日志试注释

指的是本代码文件的修改历史类，将每天的修改记录写上，这完全没有必要，可以被现代源码管理工具取代。它影响了代码阅读。f、可怕的废话注释g、能用函数或者变量的时候就不用注释h、位域标记

这类注释用于标记一个特别的位置。这种用法应该在特定的情况下使用，但是多数属于不必要的滥用。i、括号后的注释

这里指的是代码太长了，在}后添加注释表示×××代码段结束。这类注释一般是程序需要整理的标志。注释e、日志试注释注释j、归属于署名

现在源码管理可以取代，基本不需要了。k、注释掉的代码L、HTML注释

令人讨厌。m、非本地信息n、信息过多o、不明显的联系注释j、归属于署名类一、类的组织

公共静态常量、私有静态变量、私有实体变量、公共方法、私有工具函数。类一、类的组织类二、类应该短小

对于函数，我们通过计算代码行数衡量大小。对于类，我们采用不同的衡量方式，计算权责。

权责同职责，也同变化的原因。

1、类应该符合单一权责原则 2、类应该内聚 3、保持内聚会得到需要短小的类

关于类的组织这个话题比较大，比较原则性。注意理解不同设计原则之间的因果依赖关系。类二、类应该短小ThankYou!ThankYou!

读书交流会

多读书

好读书

读好书 读书交流会

多读书

好读书

读好书举头望明月低头敲代码满园春色关不住一串代码飘出来夜阑卧听风雨声做梦还在敲代码洛阳亲友如相问就说我在敲代码风萧萧兮易水寒壮士要去敲代码松下问童子言师敲代码白发三千丈Bug改不完垂死病中惊坐起今天还没敲代码在天愿做比翼鸟在地愿意敲代码但愿人长久天天敲代码献给广大不辞辛劳的程序员们举头望明月献给广大不辞辛劳的程序员们阅读本书有两种原因第一，你是个程序员第二，你想成为更好的程序员阅读本书有两种原因主要内容混乱代码的代价整洁代码艺术、什么是整洁代码如何编写整洁代码主要内容混乱代码的代价混乱代码的代价YourTextHereYourTextHere一、要有代码

有人说过我们正在临近代码的终结点。快代码就会自动产生出来不需要再人工编写。程序员完全没用了因为商务人士可以从规约直接生成程序。

代码呈现了需求的细节。混乱代码的代价YourTextHereYourText混乱代码的代价二、糟糕代码

你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验的程序员，定然多次遇到过这类困境。我们有专用来形容这事的词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。混乱代码的代价二、糟糕代码混乱代码的代价随着混乱的增加，团队生产力也持续下降趋向于零。当生产力下降时，管理层就只有一件事可做了，增加更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们制造更多的混乱，驱动生产力向零那端不断下降。混乱代码的代价随着混乱的增加，团队生产力也持续下混乱代码的代价将需求明确到机器可以执行的程度，就是编程要做的事，这种规约就是代码。糟糕的代码可能毁掉一家公司。混乱代码的代价是驱动生产力不断趋向零。整洁不仅与效率有关，而且关于企业的生存。

什么样的代码是整洁代码？混乱代码的代价将需求明确到机器可以执行的程度，就是编程要做的整洁代码代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引诱别人做没规矩的优。整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。果断决绝。代码应当讲述事实不引人猜测。它只该包含必需之物。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系而且要明确地定义和提供清晰、尽量少的API。代码应通过其字面表达含义因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。整洁代码代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关整洁代码没有测试的代码不干净。不管它有多优雅不管有多可读、多易理解微乎测试其不洁亦可知也。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么都想到了如果你企图改进它总会回到原点。能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等。整洁代码没有测试的代码不干净。不管它有多优雅不管有多可读、如何编写整洁代码命名函数注释类如何编写整洁代码命名命名一、要“名副其实” a、这件事情要严肃对待。

在起一个表意的名字上花时间是值得的，优秀程序员从细节做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：intd;//消逝的时间，以天计算

应该使用指明计量对象和计量单位的名称。 IntelapsedTimeInDays; IntdaysSinceCreation; IntdaysSinceModificatin; IntfileAgeInDays’命名一、要“名副其实”命名c、问题不在于代码的简洁度，而在于代码的“模糊度”。

这里的意思是简短的代码，如果不能表达含义，也是不能做到“名副其实”。 Demo: Java:pulicList<int[]>getThem(){ List<int[]>list1=newArrayList<int[]>(); For(int[]x:theList) If(x[0]==4) list1.add(x); returnlist1; }

这里的代码够简单了，但是没人知道theList是什么东西、theList[0]的意思是什么、d、是什么意义、以及返回list1该怎么用。

这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。命名c、问题不在于代码的简洁度，而在于代码的“模糊度”。命名二、命名要避免误导

程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList这个名字就不太好，因为list这词在java中是一个类型，如果这个名字表达的类型或者含义不是list就不应该这样命名。命名二、命名要避免误导命名三、做有意义的区分

a、不要用数字命名， Demo:a1,a2,a3。b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与ProctductData就是没有意义的区分，因为它们含义几乎一样。c、使用读得出来的名字d、使用搜索得出来的名字e、接口和实现 Demo:IShapeFactory和SharpFactory之间，选择后者作为接口名命名三、做有意义的区分函数

函数的第一条规则是要短小，第二条规则还是要短小。40年的经验告诉作者，函数就是要短小。20行封顶最佳。每个函数都一目了然，每个函数都做一件事。而且每个函数都依序把你带到下一个函数，这就是函数应该达到的短小程度。函数函数的第一条规则是要短小，第二条规则还是要短小。40年函数二、只做一件事

函数所做的事情都在一个抽象层级，叫“只做一件事”。如果各个层级抽象混杂在一起，显然就做了不止一件事了函数二、只做一件事函数三、每个函数一个抽象层级函数中混杂不同的抽象层级，往往让人迷惑。读者无法判断哪些是基础概念哪些是细节。读者无法提纲挈领的代价是，它无法快速学习，快速理解。从而为更多的bug埋下隐患。函数三、每个函数一个抽象层级函数四、使用描述性名称Demo:testtableHtmlSetupTeardownIncluder.render。如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧。函数四、使用描述性名称函数五、函数参数最好是0，其次是1，再次是2，避免3个及以上的参数个数。参数过多会使得客户程序员上手的代价加大，优秀代码的可能性降低。函数五、函数参数函数五、抽离Try/Catch代码将try/catch代码隔离出来，避免影响主程序逻辑。Demo:Try{ DeletePage(page);//DeletePage是一个方法}Catch(Exceptione){LogError(e);//LogError是一个方法}

错误处理就是一件事。函数五、抽离Try/Catch代码注释什么也比不上放置良好的注释来的有用。什么也比不上乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。注释并不像辛德勒的名单。他们并不“纯然的好”。实际上，注释最多也就是一个必须的恶，也编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释——也许根本不需要。注释什么也比不上放置良好的注释来的有用。什么也比不注释一、注释会撒谎。a、这个比较令人费解。但是它真实的存在于我们的系统中，并且是大量的存在。原因很简单，程序员不能坚持维持注释，程序存在的时间越久，注释的可信度、可读程序就很低。作者认为，程序员虽然有保持注释精读的责任，但是更应该做的是整理代码，减少注释，注释过多往往是一种程序“腐化的坏味道”。b、注释不能美化糟糕的代码。注释一、注释会撒谎。注释二、好的注释a、不可省略的涉及到法律的信息b、提供信息的注释:如果找不到好名字，则用注释提