代码坏味道与启发--《代码整洁之道》总结
代码坏味道与启发--《代码整洁之道》总结
代码坏味道与启发--《代码整洁之道》总结注释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。
记得有一次，我为了修改一个小小的功能，在那些重复的代码块里找来找去，花了整整一天的时间。
最后改完了，一测试，发现还有一处漏掉了，结果整个系统出现了严重的错误。
那时候，我真是欲哭无泪啊，感觉自己就像是个在沙漠里迷路的旅人，找不到出路。
还有那不合理的注释，有的注释比代码还长，但是却没有说到重点，全是一些无关紧要的废话。
有的地方干脆就没有注释，让我自己去猜代码的意图。
我就想问，写代码的大哥大姐们，能不能多为后来人考虑考虑啊！面对这些“代码坏味道”，我只能硬着头皮，一点点地去清理、重构。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
代码坏味道与启发--《代码整洁之道》总结
注释
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.特性依恋
类的方法应该只对自身的方法和变量感兴趣，不应该垂青其他类的方法和变量。
G15.选择算子参数
避免布尔类型参数，使用多态代替。
G16.晦涩的意图
代码要尽可能具有表达力，明白的意图比高效和性能重要。
G17.位置错误的权责
“最少惊异原则”，把代码放在读者想到的地方，而不是对自己方便的地方。
G18.不恰当的静态方法
如果要使用静态方法，必须确保没机会打算让它有多态行为。
G19.使用解释性变量
把计算过程打散成一系列命名良好的中间值使程序更加可读性。
G20.函数名称应该表达其行为
G21.理解算法
G22.把逻辑依赖改为物理依赖
依赖应该是明显而不应该是假设的依赖。
G23.用多态替代If/Else或Switch/Case
G24.遵循标准约定
G25.用命名常量替代魔术数
G26.准确
代码中的含糊和不准确要么是意见不同的结果，要么源于懒散，都必须消除。
G27.结构甚于约定
G28.封装条件
把条件封装成方法。
G29.避免否定性条件
使用肯定性条件。
G30.函数只该做一件事
G31.掩蔽时序耦合
创建顺序队列暴露时序耦合，每个函数都产生一下函数所需参数，就可保障正确的时序。
G32.别随意
代码不能随意，需要谨慎考虑。
G33.封装边界条件
例如：+1或-1操作必须封装起来。
G34.函数应该只在一个抽象层级上
封装不在一个抽象层级上的代码，保持每个函数只在一个抽象层级上。
G35.在较高层级放置可配置数据
把配置数据和常量放到基类里。
G36.避免传递浏览
“得墨忒耳律”，编写害羞代码，让直接协作者提供所需的服务，而不要逛遍整个系统。
JAVA
J1.通过使用通配符避免过长的导入清单
J2.不要继承常量
J3.常量VS.枚举
使用枚举enum代替常量。
名称
N1.采用描述性名称
名称对应可读性有90%的作用，必须认真命名。
N2.名称应与抽象层级相符
不要取沟通实现的名称：取反映类或函数抽象层级的名称。
N3.尽可能使用标准命名法
N4.无歧义的名称
N5.为较大作用范围选用较长名称
N6.避免编码
不应该在名称中包含类型或范围的信息，例如：m_，f等前缀。
N7.名称应该说明副作用
名称应该说明类、变量或函数的所有信息，不应该隐藏副作用。
测试
T1.测试不足
保证足够的测试。
T2.使用覆盖率工具
覆盖率工具可以更好地找到测试不足的模块、类、函数。
T3.别略过小测试
T4.被忽略的测试就是对不确定事物的疑问
用@Ignore表达我们对需求的疑问。
T5.测试边界条件
边界判读错误很常见，必须测试边界条件。
T6.全面测试相近的缺陷
缺陷趋向于扎堆，如果在函数中发现一个缺陷，那么就全面测试这个函数。
T7.测试失败的模式有启发性
你可以通过测试失败找到问题所在。
T8.测试覆盖率的模式有启发性
通过测试覆盖率检查，往往可以找到测试失败的线索。
T9.测试应该快速
慢测试会导致时间紧时会跳过，导致可能出现问题。