代码坏味道与启发--《代码整洁之道》总结

代码坏味道与启发--《代码整洁之道》总结注释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.特性依恋类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。

《代码整洁之道》阅读感想在编程领域，有一句经典的话：“优秀的程序员写注释，伟大的程序员无需注释。

”《代码整洁之道》这本书强调了代码的可读性和可维护性比注释更重要。

如果在敲代码这一工作岗位 3－5 年及以上，再阅读这本书，会有更深刻的理解和收获。

否则，一个小白读本书收获很少，二来，读完没有可实际操作的经历，读完收获不大。

本书属于常读常新的书籍，每次翻阅都能带来新的启示。

正如书名所暗示的，学习这些内容的目的是为了方便维护代码，让同行看起来更舒服。

此外，这本书是以 Java 语言写的例子。

如果你对 Java 语言有所了解，那么读起本书来，会更加容易理解。

以下是阅读笔记：第 4 章注释注释是代码的重要组成部分，但并非越多越好。

在大多数情况下，注释都是累赘，因此应尽可能少地使用注释。

以下是一些不好的注释类型：1. 使用代码标记某个位置（能不用就不用，就当没有）。

2. 使用代码注释作者。

3. 把不要的代码删掉，不要使用注释注释代码。

4. 注释和看懂代码无关的无用信息。

5. 为短函数选择好理解的名字，要比注释好。

然而，注释也有其存在的价值。

以下是一些好的注释类型：1. 标注注释提醒自己接下来做什么，定期查看，删除临时的 TODO 注释。

2. 使用简单明了的表达式，语句阐述这一整段代码说了什么。

3. 若他人使用这段代码，注释运行过程中遇到的情况。

4. 标注重点。

注释应该简洁明了，只提供必要的信息。

能不用注释就不用注释，除非注释能够真正帮助读者理解代码。

第 5 章格式格式对于代码的可读性和可维护性至关重要。

好的格式可以使阅读代码的人感到舒适，提高工作效率。

以下是一些关于代码格式的建议：1. 代码文件的名称要简单明了，每写一个新的模块，概念之前空一行，阅读更方便，也可以很好的区分这一个段代码做什么用。

2. 紧密相关的代码要互相靠近。

调用函数应该放在被调用函数之前。

重要的概念放在开始，细节性的代码放在下面，显示出“总分”的结构。

代码整洁之道阅读体会
《代码整洁之道》是由Robert C. Martin所著的一本关于软件工程和编程实践的经典著作。

通过阅读这本书，我对于代码整洁和良好编程实践有了更深入的理解和体会。

首先，书中强调了代码整洁的重要性。

作者指出，整洁的代码可以提高代码的可读性和可维护性，减少bug的产生，提高代码的可扩展性和重用性。

这些都是非常重要的软件质量指标，对于一个项目的长期健康发展至关重要。

其次，书中提出了许多实践性的建议和技巧，帮助读者编写整洁的代码。

比如，作者提出了单一职责原则、开闭原则、依赖倒置原则等面向对象设计的原则，以及一些具体的编码规范和技巧，例如如何命名变量、如何组织函数、如何处理异常等等。

这些建议和技巧都是作者多年实践的总结，对于提高代码的质量和开发效率都有很大的帮助。

此外，书中还介绍了一些关于团队合作和沟通的内容。

作者认为，团队合作是软件开发中至关重要的一环，而整洁的代码可以促进团队成员之间的合作，减少不必要的沟通成本，提高团队的生产
力。

总的来说，通过阅读《代码整洁之道》，我深刻理解到了编写整洁代码的重要性，以及一些实践性的方法和技巧。

这些对我个人的编程实践和团队合作都有很大的启发和帮助。

希望我对这本书的阅读体会能够对你有所帮助。

《代码整洁之道》读书心得在《代码整洁之道》这本书中，作者以深入浅出的方式讲解了编写整洁代码的重要性，以及如何通过一些简单但实用的方法来提升代码的质量。

以下是我在阅读本书过程中得到的一些心得体会：首先，书中强调了代码的命名规范。

好的命名可以让代码更易读、易懂，减少他人阅读代码时的困惑。

作者建议尽量使用有意义的变量名、函数名和类名，避免使用缩写和简写。

此外，还提出了一个很重要的观点，即命名要保持一致性，不要让阅读代码的人产生困惑。

其次，书中提到了代码的注释问题。

程序员在编写代码时，应该为复杂的逻辑或者不易理解的部分添加适当的注释，以便他人更快地理解代码的含义。

但作者也警告我们，过多的注释可能是代码本身存在问题的信号，所以在注释之前应该先想办法简化代码逻辑。

另外，书中还介绍了一些代码重构的技巧。

作者认为，不完美的代码总是可以通过重构来改善。

重构不仅可以提高代码的可读性和可维护性，还有助于消除代码中的坏味道。

而且，重构应该是一个持续的过程，随着项目的进行，不断优化代码结构是非常重要的。

此外，书中还提到了一些关于单元测试和代码复用的话题。

作者强调了单元测试的重要性，它可以帮助我们快速发现代码中的问题，并且提供了改善代码质量的途径。

而代码复用则是提高开发效率的关键，避免重复造轮子可以加快项目的进度，提高团队的效率。

总的来说，《代码整洁之道》这本书不仅让我对编写整洁代码有了更深入的理解，还教会我了很多实用的技巧和方法。

我相信，在今后的工作中，我会继续贯彻这些原则，努力提升自己的编程水平，写出更加优秀的代码。

感谢这本书给予我的启发和指导！。

关于函数——单一抽象层次原则
单一抽象层次原则SLAP(Single Level of Abstraction Principle)：让一个方法中的所有操作处于相同的抽象层。
public void performTask(HttpServletRequest request, HttpServletResponse response){ RightCheck rc = new RightCheck(); RequestAnalysis ra =new RequestAnalysis(); ResponseVO rvo=null; try { ServicrVO svo = ra.requestAnalysis(request); rvo = rc.rightCheck(svo); } catch (Exception e) { //异常处理 } PrintWriter out = null; try { out=response.getWriter(); out.write(rvo.getResponseResult()); } catch (IOException e) { //异常处理 }finally{ if(out!=null)out.close(); }
高质量的代码编写原则： 每个变量只用于单一用途 每一行代码只表达一件事 一个循环只做一件事 单一抽象层次原则 函数应该遵守单一职责 函数圈复杂度应该小于10 函数第一原则是必须要短小 编写函数时必须一心一意、专注、怀有谦虚的心态
八大原则
代码可读性——目录结构
web工程：
src：
测试目录编译后的class文件存放目录
代码健壮性——空指针问题
这段代码有什么问题没有？
public String test(String para){ …… if(para.equals(“”)){ para=“default”; …… } ……

代码整洁之道（重构）前⾔之前也介绍过我们团队的前端项⽬从零开始经历8个⽉迭代业务代码10万⾏(仅为产品长期规划需求的20%)，⾄今仍然在不断迭代的过程。

团队成员除了设计好的架构来管理这种复杂度极⾼的前端应⽤，还开始补充设计模式以及重构⽅⾯的知识，⽬的是为了让项⽬代码在不断迭代的过程中优化项⽬代码，保持代码的新鲜度，鲁棒性，可维护性… 让后续加⼊的团队新⼈也可以快速加⼊我们的产品开发中PS: 不管对于何种语⾔，重构都是软件开发过程中不可或缺的⼀部分。

如果已经了解重构的基础，可以直接跳往⾄⽂章后⾯的重构案例部分。

重构背景“如果尿布臭了，就换掉它”。

随着业务需求的不断加⼊，代码随着时间的推移变得越来越糟。

这其中可能包括以下坏味道(仅列举):重复的代码过长的函数遵循⼀条原则: 每当感觉需要注释来说明什么的时候，可以尝试将需要说明的东西写进⼀个函数中冗赘类当⼦类没有做⾜够的⼯作的时候，或者说在可见的预期内，不会有新的情况出现，考虑将类内联化。

过长的类这种情况容易出现冗余代码。

⽐如如果类内出现了多个变量带有相同的前缀或者后缀，这意味着你可以考虑把他们提炼到某个组件内，或者考虑这个组件是否可以成为⼦类，使⽤提炼类的⼿法来重构。

什么是重构我们回过头来看⼀下"什么是重构"不改变软件可观察⾏为的前提下，改善其内部结构以提⾼理解性和降低修改成本摘⾃《重构 - 改善既有代码的设计》(下⾯简称《重构》)何时重构？我们需要明确的⼀点是: 重构不是⼀件应该特地拨出⼀段时间来做的事情。

重构不是⽬的，但是重构可以帮助你把事情做好。

事不过三，三则重构重复性⼯作，既有的代码⽆法帮助你轻松添加新特性时修补bug时，排查逻辑困难code review 可以让他⼈来复审代码检查是否具备可读性，可理解性太多的代码⽆注释，已然连⾃⼰都⽆法快速理清代码逻辑重构的衡量指标数量: 代码的⾏数质量: 代码复杂度，耦合度，可读性，架构依赖复杂度等成本: 花费的时间回报(成果): ⽀持后续功能的快速叠加，解决现有因代码设计问题⽆法优化的⽭盾等抓重点抓重点啦说了这么多废话，其实⼤家都明⽩没有与实践结合的理论都是空虚的。

《代码整洁之道》读后感读书的价值，在于读者从中获得的收获。

以下是我基于自身收获对这本书的评价。

在阅读这本书之前，我认为注释是代码的重要组成部分，没有注释的代码是不完整的。

然而，我从未思考过注释与代码表达不一致的情况。

通过代码本身的命名来表达自己的想法，这是最自然、最可靠的做法。

此后，我在自己的代码中减少了不必要的注释，并不断学习谷歌命名法，使我的命名更加准确。

经过这一改变，我惊喜地发现代码如预期般变得整洁了。

在“代码看上去整洁”这一方面，这本书对我的提升非常显著。

在本书的第二和第三部分，作者通过实际案例讲解如何编写整洁的代码。

这种教学方法新颖独特，但对我来说，其实用性并没有想象中那么大。

主要原因是我没有实际实现书中的代码，导致思路经常因阅读的中断而中断，无法跟随作者的思路逐步优化代码。

我主要只看了 args 参数的例子，之后便没有继续阅读。

我认为这一部分内容需要自己多去重构代码才能真正掌握。

这两部分内容还让我了解到一个重要的名词“敏捷开发”，我觉得听作者描述这种开发方式非常酷炫。

因此，我从图书馆借阅了作者的《敏捷开发之道》，以便之后学习。

谈谈这本书的措辞。

我认为这本书的措辞只能算是通顺，有时还挺有趣，但有时也会让人觉得晦涩难懂。

而且在某些章节，特别是第二和第三部分的一些章节，会让人感觉不够完整，没有很好地“起承转合”。

可能是我过于挑剔，但像《深入理解计算机系统》这样的书籍就不会给我这种缺失感，所以在此小小地吐槽一下。

这本书对我的代码风格产生了不小的影响。

它让我认识到整洁代码的重要性，并促使我不断优化自己的代码。

代码坏味道作文作为一个程序员，每天都要和代码打交道。

这代码啊，就像是我的小伙伴，有的时候乖乖听话，有的时候却调皮捣蛋，给我带来不少麻烦。

而其中最让人头疼的，莫过于那可恶的“代码坏味道”。

就说前段时间吧，我接手了一个项目，需要对一个旧系统进行优化和改进。

当我打开那堆代码的时候，我的天，那股“坏味道”简直扑面而来，熏得我差点没背过气去。

先来说说那混乱的命名。

变量名和函数名简直就是一场噩梦，什么a、b、c 也就算了，居然还有 x1、x2 这种让人摸不着头脑的东西。

我就像个在迷宫里迷路的小白鼠，到处乱撞，试图搞清楚这些字母到底代表着什么。

有一个函数，叫“doSomething”，你能猜到它到底做了啥吗？我是猜了半天也没猜出来，看了代码才知道，它居然是用来计算两个数之和的！这名字取得也太敷衍了吧。

还有那冗长复杂的函数，一个函数几百行代码，逻辑缠缠绕绕，像一团乱麻。

我得瞪大眼睛，逐行去梳理，生怕错过了什么关键的部分。

有时候看着看着，眼睛都花了，感觉自己像是在解一道超级复杂的数学谜题，而且还没有答案提示。

更可怕的是重复的代码块。

在不同的地方，居然有着几乎一模一样的代码段，就像是克隆出来的一样。

这不仅增加了代码的体积，还让维护变得异常困难。

一旦需要修改一个功能，就得在好几个地方进行同样的修改，稍有不慎，就会漏掉一处，然后引发一系列的 bug。

记得有一次，我为了修改一个小小的功能，在那些重复的代码块里找来找去，花了整整一天的时间。

最后改完了，一测试，发现还有一处漏掉了，结果整个系统出现了严重的错误。

那时候，我真是欲哭无泪啊，感觉自己就像是个在沙漠里迷路的旅人，找不到出路。

还有那不合理的注释，有的注释比代码还长，但是却没有说到重点，全是一些无关紧要的废话。

有的地方干脆就没有注释，让我自己去猜代码的意图。

我就想问，写代码的大哥大姐们，能不能多为后来人考虑考虑啊！面对这些“代码坏味道”，我只能硬着头皮，一点点地去清理、重构。

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

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

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

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

⼀函数所有的编程都是从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. 及时要在代码之前就写好单元测试代码。

代码整洁之道-第9章-单元测试-读书笔记第 9 章 单元测试 本章介绍⼀些保持软件边界整洁的实践⼿段和技巧。

9.1 TDD 三定律 TDD 要求我们在编写⽣产代码前先编写单元测试。

三定律： 定律⼀ 在编写不能通过的单元测试前，不可编写⽣产代码。

定律⼆ 只可编写刚好⽆法通过的单元测试，不能编译也算不通过。

定律三 只可编写刚好⾜以通过当前失败测试的⽣产代码。

9.2 保持测试整洁 测试代码和⽣产代码⼀样重要。

脏测试会让测试越变越糟，维护代价增⼤。

故测试代码和⽣产代码⼀样重要。

测试带来⼀切好处 覆盖了⽣产代码的⾃动化单元测试程序组能尽可能地保持设计和架构的整洁。

测试代码了⼀切好处，因为测试使改动变得可能。

有了覆盖率⾼的测试，可以毫⽆顾虑地改进架构和设计。

9.3 整洁的测试 整洁的测试有什么要素？有三个要素：可读性，可读性和可读性。

在单元测试中，可读性甚⾄⽐在⽣产代码中还重要。

测试如何才能做到可读？和其他代码中⼀样：明确，简洁，还有⾜够的表达⼒。

在测试中，你要尽可能少的⽂字表达⼤量内容。

9.3.1 ⾯向特定领域的测试语⾔ 不直接使⽤程序员⽤来对系统进⾏操作的 API，⽽是打造了⼀套包括这些 API 的函数的⼯具代码，这样就能更⽅便地编写测试，写出来的测试也更便于测试。

⾯向特定领域（我理解为测试）的语⾔的技巧是：测试代码呈现构造-操作-检验（BUILD-OPERATE-CHECK）模式。

每个测试都清晰地拆分为三个环节。

第⼀个环节构造测试数据，第⼆环节操作测试数据，第三部分检验操作是否得到强的结果。

9.3.2 双重标准 测试 API 中的代码与⽣产代码相⽐，的确有⼀套不同的⼯程标准。

测试代码应当简单、精悍、⾜具表达⼒，但它该和⽣产代码⼀般有效。

毕竟它是在测试环境⽽⾮⽣产环境中运⾏，这两种环境有着截然不同的需求。

有些事你⼤概永远不会在⽣产环境中做，⽽在测试环境中做却完全没有问题。

通常这关乎内存或 CPU 效率（在⽣产环境不会做，但在测试环境中做却没有问题，因为不会影响测试环境的整洁）的问题，不过却永远不会与整洁有关。

读书：《代码整洁之道》刘豹目录读书：《代码整洁之道》 (1)1. 本书内容概要 (1)2. 阅读建议和相关读物推荐 (2)3. 要整洁代码的代码 (2)4. 有意义的命名 (2)4.1要“名副其实”； (2)4.2命名要避免误导 (3)4.3做有意义的区分 (3)4. 函数 (5)4.1 函数要短小、再短小 (5)4.2 只做一件事 (5)4.3 每个函数一个抽象层级 (6)4.4 使用描述性名称 (6)4.5 函数参数 (6)4.6 抽离Try/Catch代码 (7)4.7 如何写出这样的函数 (7)5. 注释 (7)5.1 核心观念 (7)5.2 好的注释 (8)5.3 坏的注释 (8)6. 格式 (9)7. 错误处理 (9)8. 边界&单元测试 (9)9. 类 (10)9.1 类的组织 (10)9.2 类应该短小 (10)10 . 其他章节 (10)1.本书内容概要核心观点：Bob大叔（即Robort.C.Martin，多本畅销书的作者，业界称其Bob大叔）认为软件质量，不仅依赖于架构及项目管理，而且与代码质量紧密相关。

而代码质量与其整洁度成正比。

核心内容：Bob大师和Object Mentor的专家以这个强大团队十几年的经验，总结了如何在代码中达到clean code，即整洁和干净的代码的经验规则。

豹：从本书的字里行间，我可以感受到Bob大叔的语重心长、循循善诱、斩钉截铁：“专业性和技艺来自于驱动规程的价值观”，也能体会到大叔的严密谨慎也感受到了他的热情和激情。

豹：书中的这些规则条款显然是经过了实战检验，非常有效的。

但我们依然不能忘记这些规则仍然是启发性规则，而不是金科玉律。

如果执着于记住条款而不思考Bob大叔提出这些条款的理由，那么收获是很有限的。

2.阅读建议和相关读物推荐阅读建议：应该说本书关于命名、注释、格式、注释、类的整理是比较经典的，可以精读。

17章是一个总结，可以拷贝重要内容在写程序时，回顾之。

《代码整洁之道》阅读感想《代码整洁之道》是一本探讨编程代码质量的经典之作，作者提出了许多关于代码整洁的原则和最佳实践。

在阅读这本书的过程中，我深受启发，对代码的编写和维护有了更深入的思考。

书中关于代码精确无二义性和效率简洁性的观点给我留下了深刻的印象。

代码就像新闻报道一样，需要精确无误地传达信息，并且要尽可能高效简洁，以节省读者的时间和心力。

这与我们日常的写作有相似之处，好的文章应该能够清晰地表达作者的意图，让读者迅速理解文章的主旨。

在代码中，精确的注释和简洁的逻辑可以提高代码的可读性和可维护性，避免冗余和重复的代码，从而提高开发效率。

关于注释，作者的观点也给了我一些反思。

注释在一定程度上确实是一种失败，因为很多注释往往是因为程序员没有写出足够好懂的代码，或者是为了弥补代码本身的不足。

然而，注释也并非完全无用，在一些情况下，注释可以提供重要的上下文信息，帮助读者更好地理解代码的功能和逻辑。

但是，注释也应该遵循精确、高效、简洁的原则，避免过度注释和无意义的注释。

此外，书中还强调了代码的结构和设计。

一个整洁的代码结构应该是分层清晰、逻辑合理的，每个模块都应该有明确的职责和功能。

这样的代码结构有助于提高代码的可读性和可维护性，也便于后续的开发和维护工作。

同时，代码的设计也应该考虑到未来的扩展性和可维护性，避免过度耦合和复杂的逻辑。

在实际的编程过程中，我也意识到了保持代码整洁的重要性。

整洁的代码不仅能够提高开发效率，还能够减少错误和调试的时间。

在团队合作中，整洁的代码也有助于提高团队的协作效率，减少代码冲突和误解。

然而，要实现代码的整洁并非一蹴而就，需要不断地学习和实践。

我们需要培养良好的编程习惯，注重代码的规范和风格，不断提高自己的代码质量。

同时，我们也需要时刻保持对代码的敬畏之心，不断反思和改进自己的代码。

《代码整洁之道》是一本非常有价值的书籍，它不仅让我对代码的编写有了更深入的理解，也让我认识到了保持代码整洁的重要性。

代码整洁之道读后感3000字大一学C语言时，我最不喜欢的事情之一就是帮其他同学调代码。

如果只是不知道怎么实现一个功能倒还好说，但往往面临的情况是，知道程序运行的结果错了，不知道代码错在哪。

不管是调试还是printf，至少要知道代码可能错在哪才好下手，这就到了最考验人耐心的时候了——看代码。

我们写的代码可谓是千人千面，我看别人的代码，仿佛是武汉人在听湖南人讲湖南话——明明说的都是中国话，怎么听不太懂呢；明明都是C语言，怎么看不太明白呢。

如果大家都是一样的编程风格，我想问题应该能得到解决。

当然，对于刚学C语言的我们来说，这只是一个美好的梦想——这个时候大局部同学应该还在为程序中各种各样的bug抓耳挠腮，无暇顾及自己编的代码是不是赏心悦目。

但问题一直存在，终究需要我们去解决，尤其是到了跳出一百来行代码的舒适圈，面对一个工程的时候。

老师在教我们汇编的时候就提到了这本书，然后我就把它下载下来，然后，就没有然后了。

这恰好验证了书中提到的勒布朗法那么：稍后等于永不〔Laterequalsnever〕。

这本书指出了很多程序员写代码时的通病，大大小小的问题使我们的代码看起来不够整洁，降低了代码的可读性——读书的时候我常常会想，这不就是说的我吗。

一．关于命名命名要名副其实，即，读者可以不通过另外的注释来了解这个变量/函数要做什么或者用来做什么。

命名要防止误导。

比方：尽量不要用一些人们熟知的命名来承载我们创造的新意义；名字之间的差距要一目了然，防止阅读代码时还要浪费时间在“找不同〞上；尽量防止用小写字母l和大写字母O作为变量名，因为它们看起来像是数字1和0······命名时要做有意义的区分。

防止a1、a2······aN式命名〔我大一时偶尔会这样偷懒命名〕，这样的命名没有任何有用信息。

使用读得出来的名称。

13
重构资料
14
重构 封面3 坏味道以及相关重构技术
坏味道 常用的重构之道
10
Refactoring to Patterns
代码坏味道的分类
11
重构手册
� 类之中的坏味道
�可度量的坏味道 �代码命名 �不必要的复杂性 �代码重复 �条件逻辑
� 类之间的坏味道
�数据 �功能职责 �相关改变 �库类
内容
� 代码的坏味道概述 � 代码坏味道的分类 � 坏味道解决之道-重构技术
2
发现代码味道对的目的
� 发现代码坏味道是我们代码评审的主要目的， 大家在一起 来挑错。同时使大家一起来熟悉这些坏味道 � 同时使大家，在自己设计和开发过程之中，尽量避免出现这 些坏味道。
生病的症状
3
中国中医-望 闻 问 切
� 中医在长期的医疗实践中，总结出了四种论断疾病的方法，这就是望、闻、
问、切四诊。
不同的症状不同的治疗方案
症状 引起的原因 不治疗的后 果 治疗的办法(药/步 骤)
4
代码坏味道
� 坏味道（Code Smell）-坏味道名称 � 症状（Symptoms）-有助于找出问题的线索 � 原因（Causes）-对问题如何会发生的说明 � 采取的措施（WhatToDo）-可能的重构 � 收益（PayOff）-代码在哪些方面有所改善 � 不适应情况-在哪些情况下不适用的情况
8
代码坏味道-2
� 5．Shotgun Surgery � 这正好和上面相反。对系统一个地方的改变涉及到其他许多地方的 相关改变。这些变化率和变化内容相似的状态和行为通常应当放在同 一个类中。 � 6．Feature Envy � 对象的目的就是封装状态以及与这些状态紧密相关的行为。假如一 个类的方法频繁用get 方法存取其他类的状态进行计算，那么你要考 虑把行为移到涉及状态数目最多的那个类。 � 7．Data Clumps � 某些数据通常像孩子一样成群玩耍：一起出现在很多类的成员变量 中，一起出现在许多方法的参数中 …..，这些数据或许应该自己独立 形成对象。 � 8．Primitive Obsession � 面向对象的新手通常习惯使用几个原始类型的数据来表示一个概念。 譬如对于范围，他们会使用两个数字。对于 Money，他们会用一个浮 点数来表示。因为你没有使用对象来表达问题中存在的概念，这使得 代码变的难以理解，解决问题的难度大大增加。 好的习惯是扩充语 言所能提供原始类型，用小对象来表示范围、金额、转化率、邮政编 码等等。

个人总结：
主要说明专业精神，程序员要精通专业技能和领域技能。 工作时间保证只做工作相关的事，并保证工作结果正常可靠。 要非工作时间要保持不断学习，反复练习，提高自身专业技能。
专业技能
设计模式，24种设计模式必须精通 设计原则，SOLID必须了解 开发应运，Xp,Scrum,瀑布，结构分分析及设计 实践，必须掌握TDD，OOD，结构化编程，持续集成，结对编程 工件，必须掌握UML图，DFD图，结构图，Petri图，状态迁移图，流程图和决策表。
代码整洁之道 --程序员的职业素养
第一章：专业主义
清楚需要什么
担当责任
不行损害之事
不要破坏软件功能 1、让QA找不出问题 2、确பைடு நூலகம்代码正常运行 3、自动化QA 不要破坏结构 1、不要破坏合理结构，合理结构让修改代码理轻松 2、大胆重构不合理结构，让结构变得合理。
职业道德
自我提升 1、坚持学习 2、反复练习 3、善于合作 4、辅导新人 5、保持谦逊
第二章：说“不"
奴隶没有权限说不，专业人士应该懂得说不。
对抗角色
需要拒绝情景
高风险时刻，项目切换、关系公司存亡，要求不合理时必须拒绝
以团队精神胁迫提出来合理要求
试试看，尝试做出来，果断拒绝。可以试试看意味没有尽力；事情有第一次必然有第二次
错误做法
无论什么要求都说是，多承诺必无信
消极对抗，承诺后不执行，拖延执行，软对抗。
站立会议
昨天做了什么
今天做什么
遇到什么问题
确定会议目标及议程
充足睡眠 跨入泥潭及时回头
第十章：预估
预估非承诺 PERT计算法 （O+4N+P)/6 亮手指估计 第十一章：压力 避免压力

《代码整洁之道》读书笔记作者：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_'前缀来表明成员变量•接口和实现别在名称中编码。