代码整洁之道读书笔记
代码坏味道与启发--《代码整洁之道》总结
代码坏味道与启发--《代码整洁之道》总结注释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.特性依恋类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。
代码整洁之道阅读体会
代码整洁之道阅读体会
《代码整洁之道》是由Robert C. Martin所著的一本关于软件工程和编程实践的经典著作。
通过阅读这本书，我对于代码整洁和良好编程实践有了更深入的理解和体会。
首先，书中强调了代码整洁的重要性。
作者指出，整洁的代码可以提高代码的可读性和可维护性，减少bug的产生，提高代码的可扩展性和重用性。
这些都是非常重要的软件质量指标，对于一个项目的长期健康发展至关重要。
其次，书中提出了许多实践性的建议和技巧，帮助读者编写整洁的代码。
比如，作者提出了单一职责原则、开闭原则、依赖倒置原则等面向对象设计的原则，以及一些具体的编码规范和技巧，例如如何命名变量、如何组织函数、如何处理异常等等。
这些建议和技巧都是作者多年实践的总结，对于提高代码的质量和开发效率都有很大的帮助。
此外，书中还介绍了一些关于团队合作和沟通的内容。
作者认为，团队合作是软件开发中至关重要的一环，而整洁的代码可以促进团队成员之间的合作，减少不必要的沟通成本，提高团队的生产
力。
总的来说，通过阅读《代码整洁之道》，我深刻理解到了编写整洁代码的重要性，以及一些实践性的方法和技巧。
这些对我个人的编程实践和团队合作都有很大的启发和帮助。
希望我对这本书的阅读体会能够对你有所帮助。
《代码整洁之道》读后感
《代码整洁之道》读后感读书的价值，在于读者从中获得的收获。
以下是我基于自身收获对这本书的评价。
在阅读这本书之前，我认为注释是代码的重要组成部分，没有注释的代码是不完整的。
然而，我从未思考过注释与代码表达不一致的情况。
通过代码本身的命名来表达自己的想法，这是最自然、最可靠的做法。
此后，我在自己的代码中减少了不必要的注释，并不断学习谷歌命名法，使我的命名更加准确。
经过这一改变，我惊喜地发现代码如预期般变得整洁了。
在“代码看上去整洁”这一方面，这本书对我的提升非常显著。
在本书的第二和第三部分，作者通过实际案例讲解如何编写整洁的代码。
这种教学方法新颖独特，但对我来说，其实用性并没有想象中那么大。
主要原因是我没有实际实现书中的代码，导致思路经常因阅读的中断而中断，无法跟随作者的思路逐步优化代码。
我主要只看了 args 参数的例子，之后便没有继续阅读。
我认为这一部分内容需要自己多去重构代码才能真正掌握。
这两部分内容还让我了解到一个重要的名词“敏捷开发”，我觉得听作者描述这种开发方式非常酷炫。
因此，我从图书馆借阅了作者的《敏捷开发之道》，以便之后学习。
谈谈这本书的措辞。
我认为这本书的措辞只能算是通顺，有时还挺有趣，但有时也会让人觉得晦涩难懂。
而且在某些章节，特别是第二和第三部分的一些章节，会让人感觉不够完整，没有很好地“起承转合”。
可能是我过于挑剔，但像《深入理解计算机系统》这样的书籍就不会给我这种缺失感，所以在此小小地吐槽一下。
这本书对我的代码风格产生了不小的影响。
它让我认识到整洁代码的重要性，并促使我不断优化自己的代码。
《代码整洁之道》总结和笔记
《代码整洁之道》总结和笔记前⾔《代码整洁之道》在业内有很⾼的知名度，被诸多前辈推荐给后来者阅读。
本书以循序渐进改造⼀个⼩程序的⽅式，演⽰了⼀个程序可能的各种设计（在代码层⾯）。
⼿把⼿教你该怎么设计代码，为何要这样设计，这样设计的好处是什么。
通过⼀周的阅读，总结了如下要点。
⼀函数所有的编程都是从HellWorld这个⼩函数开始的，学会设计函数⾮常重要1. 函数要短。
短才⽅便阅读、维护和设计。
(每个⼈都经历过读不懂⾃⼰代码的尴尬)2. 函数只做⼀件事。
依照单⼀职责原则设计函数。
⼀个函数可以:流程控制，逻辑判断，改变变量状态，以及做运算，或者调⽤多个下⼀抽象级的函数。
3. 函数分解成多个抽象层级设计，⾼层函数只调⽤下次层函数，呈树状图，层层封装。
4. 函数不应该有标识参数(除了作为API的函数)，这意味着函数有⾄少两种执⾏⽅式，违反了第2条原则。
⽽且明显能拆成多个⼩函数。
5. 函数参数越少越好有，多个参数应该封装成⼀个整体传⼊的。
如果逻辑上不是⼀个整体，则函数肯定能被拆成多个⼩函数然后被分别调⽤。
第4条标识参数可以封装进整体传⼊函数，⽽不是直接作为函数的参数6. 函数真的最好只做⼀件事，不要为了⼀时⽅便顺⼿加⼏⾏代码。
如登录验证时，函数⽤来验证username和password，在验证之后顺便给⽤户初始化些其他东西。
会导致这个函数在其他时候⽆法验证⽤户信息。
7. 底层函数不应该改变参数状态，如果想改变某类的状态，就把该函数加⼊该类，让它⾃⼰调⽤函数。
如：把改变类x的状态的函数调⽤addFooter(x)，改为x.addFooter()。
8. 函数不要返回错误码，这需要你有错误码的枚举类，并且违反了开放封闭原则（你需要加⼊新错误码来扩展新错误），直接抛出异常就好了。
（可以通过继承⽗异常来扩展）。
但是实际上错误码的应⽤不⽐异常少，⽽且异常也会导致代码的臃肿。
9. 函数名称应该描述清楚函数作⽤，避免频繁去看⽂档，这对于短⼩的函数来说不难办到，如果很难命名可能需要思考函数是否有依照以上原则设计(你⼀个函数可能做了很多事情)。
读书笔记《代码整洁之道》单元测试
读书笔记《代码整洁之道》单元测试
TDD三定律
定律⼀：在编写不能通过的单元测试之前，不可以编写⽣产代码
写⽣产代码之前，⼀定要写好可靠的单元测试代码
定律⼆：只可编写刚好⽆法通过的单元测试，不能编译也算不通过
只能编写刚好⽆法通过的单元测试代码，也就是说⼀次性只需要写⼀个单元测试代码，不要在⼀个单元测试⾥写太多的测试场景。
定律三：只可编写刚好⾜以通过当前失败测试的⽣产代码
只能编写刚好单元测试会失败的⽣产代码，就是⼀次只能写符合⼀个单元测试要求的代码，写了⼀个case 就⼀段对应的代码
个⼈总结：
1. 单元测试放在代码之前写
2. 单元测试只写当前要测试的功能的场景
3. 只写第⼆步单元测试覆盖的代码。
整洁的测试
单元测试代码三要素：
可读性，可读性，可读性
整洁的测试代码三个步骤：
构造（测试数据）—> 操作—>检验
测试代码⼯程标准：
简单，精悍，⾜具表现⼒，不需要考虑资源消耗（因为不会部署，所以⽆需考虑）。
每个测试只有⼀个断⾔。
每个测试函数只测试⼀个概念。
整洁测试的五个原则：
1. 快速运⾏速度快
2. 独⽴测试相互独⽴，不需要某个测试作为前提条件，⾃⼰也不是某个测试的前提条件，不需要按照顺序
3. 可重复不需要区分环境
4. 可以⾃证会返回布尔值，不需⼿动去⽐对。
5. 及时要在代码之前就写好单元测试代码。
《代码整洁之道》阅读感想
《代码整洁之道》阅读感想《代码整洁之道》是一本探讨编程代码质量的经典之作，作者提出了许多关于代码整洁的原则和最佳实践。
在阅读这本书的过程中，我深受启发，对代码的编写和维护有了更深入的思考。
书中关于代码精确无二义性和效率简洁性的观点给我留下了深刻的印象。
代码就像新闻报道一样，需要精确无误地传达信息，并且要尽可能高效简洁，以节省读者的时间和心力。
这与我们日常的写作有相似之处，好的文章应该能够清晰地表达作者的意图，让读者迅速理解文章的主旨。
在代码中，精确的注释和简洁的逻辑可以提高代码的可读性和可维护性，避免冗余和重复的代码，从而提高开发效率。
关于注释，作者的观点也给了我一些反思。
注释在一定程度上确实是一种失败，因为很多注释往往是因为程序员没有写出足够好懂的代码，或者是为了弥补代码本身的不足。
然而，注释也并非完全无用，在一些情况下，注释可以提供重要的上下文信息，帮助读者更好地理解代码的功能和逻辑。
但是，注释也应该遵循精确、高效、简洁的原则，避免过度注释和无意义的注释。
此外，书中还强调了代码的结构和设计。
一个整洁的代码结构应该是分层清晰、逻辑合理的，每个模块都应该有明确的职责和功能。
这样的代码结构有助于提高代码的可读性和可维护性，也便于后续的开发和维护工作。
同时，代码的设计也应该考虑到未来的扩展性和可维护性，避免过度耦合和复杂的逻辑。
在实际的编程过程中，我也意识到了保持代码整洁的重要性。
整洁的代码不仅能够提高开发效率，还能够减少错误和调试的时间。
在团队合作中，整洁的代码也有助于提高团队的协作效率，减少代码冲突和误解。
然而，要实现代码的整洁并非一蹴而就，需要不断地学习和实践。
我们需要培养良好的编程习惯，注重代码的规范和风格，不断提高自己的代码质量。
同时，我们也需要时刻保持对代码的敬畏之心，不断反思和改进自己的代码。
《代码整洁之道》是一本非常有价值的书籍，它不仅让我对代码的编写有了更深入的理解，也让我认识到了保持代码整洁的重要性。
精选《代码整洁之道》读后感3000字
代码整洁之道读后感3000字大一学C语言时，我最不喜欢的事情之一就是帮其他同学调代码。
如果只是不知道怎么实现一个功能倒还好说，但往往面临的情况是，知道程序运行的结果错了，不知道代码错在哪。
不管是调试还是printf，至少要知道代码可能错在哪才好下手，这就到了最考验人耐心的时候了——看代码。
我们写的代码可谓是千人千面，我看别人的代码，仿佛是武汉人在听湖南人讲湖南话——明明说的都是中国话，怎么听不太懂呢；明明都是C语言，怎么看不太明白呢。
如果大家都是一样的编程风格，我想问题应该能得到解决。
当然，对于刚学C语言的我们来说，这只是一个美好的梦想——这个时候大局部同学应该还在为程序中各种各样的bug抓耳挠腮，无暇顾及自己编的代码是不是赏心悦目。
但问题一直存在，终究需要我们去解决，尤其是到了跳出一百来行代码的舒适圈，面对一个工程的时候。
老师在教我们汇编的时候就提到了这本书，然后我就把它下载下来，然后，就没有然后了。
这恰好验证了书中提到的勒布朗法那么：稍后等于永不〔Laterequalsnever〕。
这本书指出了很多程序员写代码时的通病，大大小小的问题使我们的代码看起来不够整洁，降低了代码的可读性——读书的时候我常常会想，这不就是说的我吗。
一．关于命名命名要名副其实，即，读者可以不通过另外的注释来了解这个变量/函数要做什么或者用来做什么。
命名要防止误导。
比方：尽量不要用一些人们熟知的命名来承载我们创造的新意义；名字之间的差距要一目了然，防止阅读代码时还要浪费时间在“找不同〞上；尽量防止用小写字母l和大写字母O作为变量名，因为它们看起来像是数字1和0······命名时要做有意义的区分。
防止a1、a2······aN式命名〔我大一时偶尔会这样偷懒命名〕，这样的命名没有任何有用信息。
使用读得出来的名称。
《代码整洁之道》笔记——第七章：错误处理
《代码整洁之道》笔记——第七章：错误处理
1、使⽤异常⽽⾮错误码，因为错误码容易搞乱代码逻辑。
2、在编写可能抛出异常的代码时，最好先写出try-catch-finally语句。
这能帮你定义代码的⽤户应该期待什么，⽆论try代码块中执⾏的代码出什么错都⼀样。
3、使⽤不可控异常，因为可控异常打破了封装，⾼层函数调⽤底层函数必须知道底层函数的异常细节。
4、应创建信息充分的错误消息，并和异常⼀起传递出去。
5、定义异常类时，最重要的考虑应该是它们如何被捕获。
6、将第三⽅API打包是个良好的实践⼿段。
当你打包⼀个第三⽅API，你就降低了对它的依赖：未来你可以不太痛苦地改⽤其他代码库。
7、别返回null值。
因为返回null值，基本上是在给⾃⼰增加⼯作量，也是在给调⽤者添乱。
只要有⼀处没检查null值，应⽤程序就会失控。
8、别传递null值。
除⾮API要求你向它传递null值，否则就要尽可能避免传递null值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
混乱代码的代价
• 将需求明确到机器可以执行的程度，就是编程要做 的事，这种规约就是代码。
• 糟糕的代码可能毁掉一家公司。 • 混乱代码的代价是驱动生产力不断趋向零。 • 整洁不仅与效率有关，而且关于企业的生存。
什么样的代码是整洁代码？
整洁代码
• 代码逻辑应当直截了当，叫缺陷难以隐藏，尽量减少依赖关系，使之便 于维护，依据某种分层战略完善错误处理代码，性能调至最优，省得引 诱别人做没规矩的优。
函数
三、每个函数一个抽象层级
函数中混杂不同的抽象层级，往往让人迷惑。读者无法判 断哪些是基础概念哪些是细节。
读者无法提纲挈领的代价是，它无法快速学习，快速理解
Demo:testtableHtmlSetupTeardownIncluder.rend er。
随着混乱的增加，团队生产力也持续下降趋向于 零。当生产力下降时，管理层就只有一件事可做 了，增加更多人手到项目中，期望提升生产力。 可是新人并不熟悉系统的设计。他们搞不清楚什 么样的修改符合设计意图，什么样的修改违背设 计意图。而且，他们以及团队中的其他人都背负 着提升生产力的可怕压力。于是，他们制造更多 的混乱，驱动生产力向零那端不断下降。
阅读本书有两种原因 第一，你是个程序员 第二，你想成为更好的程序员
主要内容
• 混乱代码的代价 • 整洁代码艺术、什么是整洁代码 • 如何编写整洁代码
混乱代码的代价
一、要有代码
有人说过我们正在临近代码的终结点。快代码就会自动产生出 规约直接生成程序。
代码呈现了需求的细节。
混乱代码的代价
二、糟糕代码
命名
• 二、命名要避免误导
程序员必须避免留下掩藏代码本意的错误线索。 Demo:accountList 这 个 名 字 就 不 太 好 ， 因 为 list 这 词 在 java中是一个类型，如果这个名字表达的类型或者含义不是 list就不应该这样命名。
命名
• 三、做有意义的区分
a、不要用数字命名， Demo:a1,a2,a3。
DeletePage(page);//DeletePage是一个方法 } Catch(Exception e){
b、话是另一种没有意义的区分， Demo：如有有一个类叫Product类，那么ProductInfo与
ProctductData就是没有意义的区分，因为它们含义几乎一样。 c、使用读得出来的名字 d、使用搜索得出来的名字 e、接口和实现
Demo:IShapeFactory和SharpFactory之间，选择后者作为接口 名
你是否曾为糟糕的代码所深深困扰？如果你是位有点儿经验 的程序员，定然多次遇到过这类困境。我们有专用来形容这事的 词：沼泽。我们趟过代码的水域。我们穿过灌木密布、瀑布暗藏 的沼泽地。我们拼命想找到出路，期望有点什么线索能启发我们 到底发生了什么事，但目光所及，只是越来越多死气沉沉的代码。
混乱代码的代价
函数
• 函数的第一条规则是要短小，第二条规则还是要短小。40
年的经验告诉作者，函数就是要短小。 • 20行封顶最佳。 • 每个函数都一目了然，每个函数都做一件事。而且每个函数
都依序把你带到下一个函数，这就是函数应该达到的短小程 度。
函数
二、只做一件事
函数所做的事情都在一个抽象层级，叫“只做一件事”。 如果各个层级抽象混杂在一起，显然就做了不止一件事了
命名
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; }
• 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐 藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
• • 它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而
和提供清晰、尽量少的API 语言导致并非所有必需信息均可通过代码自身清晰表达。
整洁代码
• • 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的 • 能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽
读书交流会
多读书 好读书 读好书
献给广大不辞辛劳的程序员们
在在今垂
壮风就洛做夜一满
Bug
天但地天天死 白言松士萧说阳梦阑串园低举
天愿愿愿还病 发师下要萧我亲还卧代春头头
敲人意做没中改三敲问去兮在友在听码色敲望
代长敲比敲惊不千代童敲易敲如敲风飘关代明
码久代翼代坐完丈码子代水代相代雨出不码月
码鸟码起
码寒码问码声来住
这里的代码够简单了，但是没人知道 theList是什么东西、theList[0]的意思是什么、 d、是什么意义、以及返回list1该怎么用。
这就是作者所说的“模糊度”，因为意义比较模糊，所以这些代码也不“名副其实”。 那么怎么呢？应该根据这段代码的意图来修改这里的函数名，变量名，值的含义（用常量）。
量少的实体，比如类、方法、函数等。
如何编写整洁代码
• 命名 • 函数 • 注释 •类
命名
一、要“名副其实” a、这件事情要严肃对待。 在起一个表意的名字上花时间是值得的，优秀程序员从细节 做起。 b、如果名称需要注释来补充，那就不是“名副其实”。 Demo：int d;//消逝的时间，以天计算 应该使用指明计量对象和计量单位的名称。 Int elapsedTimeInDays; Int daysSinceCreation; Int daysSinceModificatin; Int fileAgeInDays’
如果长一点的名称可以更加清晰，不要犹豫，用清晰的吧。
函数
五、函数参数 最好是0，其次是1，再次是2，避免3个及以上的参数个
数。 参数过多会使得客户程序员上手的代价加大，优秀代码的
可能性降低。
函数
五、抽离Try/Catch代码
将try/catch代码隔离出来，避免影响主程序逻辑。 Demo: Try{