代码整洁之道读书笔记30页PPT

代码坏味道与启发--《代码整洁之道》总结注释C1.不恰当的注释让不恰当的注释保存到源代码控制系统。

C2.废弃的注释过时、无关或不正确的注释就是废弃的注释不应该保留必须马上删除。

C3.冗余的注释注释应该谈及代码自身没提到的东西，否则就是冗余的。

C4.糟糕的注释值得编写的注释必须正确写出最好的注释，如果不是就不要写。

C5.注释掉的代码注释掉的代码必须删除。

环境E1.需要多步才能实现的构建构建系统应该是单步的小操作。

E2.需要多步才能实现的测试只需要单个指令就可以运行所有单元测试。

函数F1.过多的参数函数参数应该越少越好，坚决避免有3个参数 的函数。

F2.输出参数输出参数违反直接，抵制输出参数。

F3.标识参数布尔值参数令人迷惑，应该消灭掉。

F4.死函数永不被调用函数应该删除掉。

一般性问题G1.一个源文件存在多个语言尽量减少源文件语言的数量和范围。

G2.明显的行为未被实现遵循“最少惊异原则”，函数或者类应该实现其他程序员有理由期待的行为，不要让其他程序员看代码才清楚函数的作用。

G3.不正确的边界行为代码应该有正确的行为，追索每种边界条件并进行全面测试。

G4.忽视安全关注可能引起问题的代码，注重安全与稳定。

G5.重复消除重复代码，使用设计模式。

G6.在错误的抽象层级上的代码抽象类和派生类概念模型必须完整分离，例如：与实现细节有关的代码不应该在基类中出现。

G7.基类依赖于派生类基类应该对派生类一无所知。

G8.信息过多类中的方法，变量越少越好，隐藏所有实现，公开接口越少越好。

G9.死代码找到并删除所有不被调用的代码。

G10.垂直分隔变量和函数的定义应该靠近被调用代码。

G11.前后不一致函数参数变量应该从一而终，保持一致，让代码便于阅读和修改。

G12.混淆视听没用的变量，不被调用的函数，没有信息量的注释应该清理掉。

G13.人为耦合不互相依赖的东西不该耦合。

G14.特性依恋类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。

《架构整洁之道》读书笔记1. 设计与架构软件架构的终极⽬标是，⽤最⼩的⼈⼒成本来满⾜构建和维护该系统的需求。

⼀个软件架构的优劣，可以⽤它满⾜⽤户需求所需要的成本来衡量。

如果该成本很低，且在系统的⽣命周期内始终很低，那么这个系统的设计就是优良的。

反之，就是不好的设计。

胡乱编写代码的⼯作速度，其实⽐循规蹈矩更慢。

要想跑得快，先要跑得稳。

2. 两个价值维度⾏为价值：程序按照需求⽂档要求的⽅式⼯作架构价值：软件的“软”，即软件的灵活性艾森豪威尔矩阵重要且紧急重要不紧急不重要但紧急不重要且不紧急紧急的事情往往没那么重要，⽽重要的事情似乎永远也排不上优先级。

第⼀个价值维度：系统⾏为，是紧急的，但是并不总是特别重要。

第⼆个价值维度：系统架构，是重要的，但是并不总是特别紧急。

应有的排序：重要且紧急重要不紧急不重要但紧急不重要且不紧急常犯的错误：将第三优先级的事情提到第⼀优先级去做。

导致重要的事情被忽略。

平衡系统架构的重要性与功能的紧急程度，是软件研发⼈员⾃⼰的职责。

建议：为好的软件架构⽽持续⽃争研发团队必须从公司长远利益出发，与其他部门抗争，公司内部的抗争本来就是⽆⽌境的。

软件的可维护性需要由你来保护，这是你的职责，公司雇你的很⼤⼀部分原因就是需要有⼈来做这件事。

3. 编程范式编程范式指的是程序的编写模式。

⼀共只有三种编程范式，⽽且未来⼏乎不可能再出现新的（理由是，编程范式都是增加限制，Bob⼤叔的理解）。

⼀本谈软件架构的书，为什么要设计编程范式呢？Bob⼤叔如是说：多态是我们跨越架构边界的⼿段，函数式编程是我们规范和限制数据存放位置与访问权限的⼿段，结构化编程则是各模块的算法实现的基础。

这和软件架构的三⼤关注重点不谋⽽合：功能性、组件独⽴性、数据管理。

结构化编程可推导性：可以⽤代码将⼀些已证明可⽤的结构串联起来，只要证明额外的代码是正确的，就可以推导出整个程序的正确性goto语句的某些⽤法会导致某个模块⽆法被递归拆分成更⼩的、可证明的单元。

《代码整洁之道》总结和笔记前⾔《代码整洁之道》在业内有很⾼的知名度，被诸多前辈推荐给后来者阅读。

本书以循序渐进改造⼀个⼩程序的⽅式，演⽰了⼀个程序可能的各种设计（在代码层⾯）。

⼿把⼿教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。

通过⼀周的阅读，总结了如下要点。

⼀函数所有的编程都是从HellWorld这个⼩函数开始的，学会设计函数⾮常重要1. 函数要短。

短才⽅便阅读、维护和设计。

(每个⼈都经历过读不懂⾃⼰代码的尴尬)2. 函数只做⼀件事。

依照单⼀职责原则设计函数。

⼀个函数可以:流程控制，逻辑判断，改变变量状态，以及做运算，或者调⽤多个下⼀抽象级的函数。

3. 函数分解成多个抽象层级设计，⾼层函数只调⽤下次层函数，呈树状图，层层封装。

4. 函数不应该有标识参数(除了作为API的函数)，这意味着函数有⾄少两种执⾏⽅式，违反了第2条原则。

⽽且明显能拆成多个⼩函数。

5. 函数参数越少越好有，多个参数应该封装成⼀个整体传⼊的。

如果逻辑上不是⼀个整体，则函数肯定能被拆成多个⼩函数然后被分别调⽤。

第4条标识参数可以封装进整体传⼊函数，⽽不是直接作为函数的参数6. 函数真的最好只做⼀件事，不要为了⼀时⽅便顺⼿加⼏⾏代码。

如登录验证时，函数⽤来验证username和password，在验证之后顺便给⽤户初始化些其他东西。

会导致这个函数在其他时候⽆法验证⽤户信息。

7. 底层函数不应该改变参数状态，如果想改变某类的状态，就把该函数加⼊该类，让它⾃⼰调⽤函数。

如：把改变类x的状态的函数调⽤addFooter(x)，改为x.addFooter()。

8. 函数不要返回错误码，这需要你有错误码的枚举类，并且违反了开放封闭原则（你需要加⼊新错误码来扩展新错误），直接抛出异常就好了。

（可以通过继承⽗异常来扩展）。

但是实际上错误码的应⽤不⽐异常少，⽽且异常也会导致代码的臃肿。

9. 函数名称应该描述清楚函数作⽤，避免频繁去看⽂档，这对于短⼩的函数来说不难办到，如果很难命名可能需要思考函数是否有依照以上原则设计(你⼀个函数可能做了很多事情)。

代码整洁之道【笔记】一、整洁代码A.混乱的代价1.有些团队在项目初期进展迅速，但有那么一两年的时间却慢去蜗行。

对代码的每次修改都影响到其他两三处代码2.花时间保持代码整洁不但有关效率，还有关生存3.程序员遵从不了解混乱风险经理的意愿，也是不专业的做法4.Bjarne Stroustrup，C++发明者：我喜欢优雅和高效的代码。

代码逻辑应该直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。

整洁的代码只做好一件事。

5.Grady Booch，《面向分析与设计》：整洁的代码简单直接。

整洁的代码如同优美的散文。

整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直接了当的控制语句。

6.Dave Thomas，OTI公司创始人：整洁的代码应可由作者之外的开发者阅读和增补。

它应有单元测试和验收测试。

它使用有意义的命名。

它只提供一种而非多种做一件事的途径。

它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的API。

代码应通过其字面表达含义，因为不同的语言导致并非所有必须信息均可通过代码自身清晰表达。

7.Michael Feathers，《修改代码的艺术》：我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。

整洁的代码总是看起来像是某位特别在意它的人写的。

几乎没有改进的余地。

代码作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。

8.Ron Jeffries，《极限编程实施》：简单代码，依其重要顺序：能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等9.Ward Cunningham，Wiki发明者：如果每个例程都让你感到深合已意，那就是整洁代码。

如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。

本文是关于Bob大叔关于整洁架构的一篇学习笔记。

前言整洁架构(Clean Architecture)是由Bob大叔在2012年提出的一个架构模型，顾名思义，是为了使架构更简洁。

在开始深入的介绍这个架构之前，Bob大叔首先提到了近些年来比较流行的一个系统架构，包括Hexagonal Architecture，Onion Architecture，以及他自己以前提出的Screaming architecuture等。

并且着中说道通过这些架构产生的系统特点是：独立的框架. 这样的架构并不依赖与应用软件的具体库包，这样可以将框架作为工具，而不必将你的系统都胡乱混合在一起。

可测试. 业务规则能够在没有UI和数据库或Web服务器的情况下被测试。

UI的独立性. UI改变变得容易，不必改变系统的其余部分，一个Web UI能被一个控制台或专门的图形UI替代, 这些读不必更改业务核心规则。

数据库的独立性. 你能够在Oracle或SQL Server Mongo, BigTable, CouchDB,或之间切换, . 你的业务规则不会和数据库绑定独立的外部代理，其实你的业务规则可以对其外面的技术世界毫无所知，比如是否使用了MVC或DCI都可以不关心。

好的，接下来一起了解一下clean architecture：依赖规则(Dependency Rule)用一组同心圆来表示软件的不同领域。

一般来说，越深入代表你的软件层次越高。

外圆是战术是实现机制(mechanisms)，内圆的是核心原则(policy)。

Policy means the application logic.Mechanism means the domain primitives.这条规则规定软件模块只能向内依赖，而里面的部分对外面的模使此体系架构能够工作的关键是依赖规则。

这条规则规定软件模块只能向内依赖，而里面的部分对外面的模块一无所知，也就是内部不依赖外部，而外部依赖内部。

代码整洁之道-第4章-注释-读书笔记第 4 章 注释 “别给糟糕的代码加注释—重新写吧。

” — Brian W,Kernighan 与 P.J.Plaugher 什么也⽐不上放置良好的注释来得有⽤。

什么也不会⽐乱七⼋糟的注释更有本事搞乱⼀个模块。

什么也不会⽐陈旧、提供错误信息的注释更有破坏性。

注释的恰当⽤法是弥补我们在⽤代码表达意图时遭遇的失败。

我们总⽆法找到不⽤注释就能表达⾃我的⽅法，所以总要有注释，这不值得庆贺。

如果你发现⾃⼰需要写注释，再想想看是否有办法翻盘，⽤代码来表⽰。

注释存在的事件越久，就离其所描述的代码越远，越来越变得全然错误。

原因很简单。

程序员不能坚持维护注释。

程序员应当负责将注释保持在可维护、有关联、精确的⾼度。

但我更主张把⼒⽓⽤在写清楚代码上，直接保证⽆序编写注释。

不准确的注释要⽐没注释的代码坏的多。

尽管有时也需要注释，我们也该多花⼼思尽量减少注释量。

4.1 注释不能美化糟糕的代码 写注释的常见动机之⼀是糟糕的代码的存在。

带有少量注释的整洁⽽有表达⼒的代码，要⽐带有⼤量注释的零散⽽复杂的代码像样的多。

与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码。

4.2 ⽤代码来阐述 只要想上那么⼏秒钟，就能⽤代码解释你⼤部分的意图。

很多时候，简单到只需要创建⼀个描述与注释所⾔同⼀事物的函数即可。

4.3 好注释 唯⼀真正好的注释是你想办法不去写的注释。

4.3.1 法律信息 有时，公司代码规范要求编写与法律相关的注释。

例如，版权及著作权声明就是必须和有理由在每个源⽂件开头注释处放置的内容。

这类注释不应是合同或法典。

只要有可能，就指向⼀份标准许可或其他外部⽂件，⽽不要把所有条款放到注释中。

4.3.2 提供信息的注释 有时，⽤注释来提供基本信息也有其⽤处。

这类注释有时管⽤，但更好的⽅式是尽量利⽤函数名称传达信息。

4.3.3 对意图的解释 有时，注释不仅提供了有关实现的有⽤信息，⽽且还提供了某个决定后⾯的意图。

《代码整洁之道》读书笔记作者：llinvokerl看完《代码整洁之道》之后我受益匪浅，但等到自己实践时却很难按照书中给的建议编写出整洁的代码。

一方面是规则太多，记不住，另一方面书上引用了大量示例代码对这些规则进行佐证，在我记不住时亦不方便查阅。

于是我把书中的规则摘了出来并加以一定的解释，闲暇时候多过几遍，希望这些规则时刻警示我，成为我的习惯。

想看此书却还没开始的人也可以从这篇笔记出发，对笔记中列出的规则有疑问再翻书找答案，相信会比直接啃书来的快一些。

ps: 未必要严格遵循书中的规则，代码不是八股文。

命名1.避免误导•'一组账号'别用accountList表示，List对程序员有特殊含义，可以用accountGroup、bunchOfAccounts、甚至是accounts•不使用区别较小的名称，ZYXControllerForEfficientHandlingOfStrings和ZYXControllerForEfficientStorageOfStrings难以辨别•不使用小写l、大写O作变量名，看起来像常量1、02.做有意义的区分•不以数字系列命名(a1、a2、a3)，按照真实含义命名•Product/ProductInfo/ProductData 意思无区别，只统一用一个•别写冗余的名字，变量名别带variable、表名别带table3.使用可搜索的名称•单字母名称和数字常量很难在上下文中找出。

名称长短应与其作用域大小相对应，越是频繁出现的变量名称得越容易搜索(越长)4.命名时避免使用编码•把类型和作用域编码进名称里增加了解码负担。

意味着新人除了了解代码逻辑之外，还需要学习这种编码语言。

•别使用匈牙利语标记法(格式：[Prefix]-BaseTag-Name 其中BaseTag是数据类型的缩写，Name是变量名字)，纯属多余•不必用'm_'前缀来表明成员变量•接口和实现别在名称中编码。

01-代码整洁之道3天版课件CleanCode代码整洁之道一、为什么需要该课程软件质量,不但依赖于架构,设计以及项目管理,而且与代码质量紧密相关.这一点,无论你使用什么开发技术,都不得不承认.代码是程序员沟通最直接的手段，代码是技术交流的手段，代码是需求交流的途径。

重视代码，回归本源，曾经我们远离代码，谈架构设计，谈UML,谈开发流程。

如今我们落地,找回软件的本源，彻彻底底看清代码、深入思考代码。

那些一流的研发中心非常重视代码,Facebook就有经典的Code wins arguments（代码赢得争论）。

在Facebook 做code review时间大约占50%，管理者对代码质量负有一定责任。

甚至代码质量高于一切：Facebook Code review 是重点KPI考核的对象，实行连坐制，如果因为代码质量问题，那么产生的KPI责任包括领导30％、程序员50％、审核人员20％。

但是我们的管理者经常听到开发人员这样抱怨：“不能再增加功能了！我们得停下来重写代码。

软件代码一团糟，就像纸糊的老虎，根本应付不了持续增加的用户需求。

我们实在维护不下去了！最好推倒重写吧”这一幕在很多公司上演过，现在依然在不断重演。

一旦公司陷入这种困境，以前版本的开发者往往沦为替罪羊。

新的开发者一般就会骂前人怎么写这么烂的代码。

他们准备推倒重来，准备重写系统。

在重写代码的过程中，用户无法看到产品的任何改进。

你可能认为重写代码至多也就几个月，但是实际花费的时间无一例外要多得多。

你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。

我们研发中心有一个理念”代码是债务而不是资产”。

最开始，团队会编写代码，做出产品，并用它来赚钱，但是，之后团队应该尽可能地寻找减少代码的方法和使代码尽量整洁，从而降低成本。

软件界有一个真理，你拥有的代码越多，维护代码所要付出的成本就越高。

如果你的代码结构越好，你做了越多的单元测试，你的代码质量越好、越小、耦合越松，那么添加新代码所需要付出的成本就越少。

《Clean Code》读后感《Clean Code》读后感品味完一本名著后，大家心中一定有不少感悟，为此需要认真地写一写读后感了。

是不是无从下笔、没有头绪？以下是小编整理的《Clean Code》读后感，希望对大家有所帮助。

最近浅读了《Clean Code》这本书，虽然由于知识水平的有限，很多地方没有理解透彻，但还是令我受益颇多。

毫无置疑，软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。

这本书围绕“代码质量与其整洁度成正比”给出了一系列论述以及行之有效的整洁代码操作实践，“干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础”。

第一章论述了“整洁代码”。

虽然我还没有丰富的工程实践经历，但是第一章中提出的一种错误的想法“能运行的烂程序总比什么都没有强”非常熟悉，在以往写简单的练习题时，即使代码量很小，我首要追求的就是AC这道题，对代码质量不管不顾，它也解释了这种做法的原因，即：希望快点完成，早点结束手上的任务。

然而，制造混乱将会带来巨大的代价，往往混乱的代码在以后的维护中将会越来越混乱，随着混乱的增加，生产力将会降低趋向于零，后果不堪设想。

开发者一方面被之前的混乱拖后腿，另一方面背负期限的压力只好制造混乱，程序员太难了。

文中提到做的快的唯一方法就是始终尽可能保持代码整洁，可是我又不能让我之前的开发者保持代码的整洁，那这样就导致程序员一方面要忍受之前的开发者制造的混乱，又要努力从现在开始尽量保持代码的整洁，还是太难了，所以往往糟糕的代码只会越来越烂，但是不能因为困难就制造混乱，我们要做负责任的开发者、程序员，不仅要为我们的project负责，也是为后来的开发、维护人员负责。

保持代码整洁，停止制造混乱，从我做起。

不同的人对整洁代码的定义不同，文中记录了一些厉害的程序员的看法，比如Bjarne说“我喜欢优雅和高效的代码。

代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱。