代码整洁之道读书笔记

代码坏味道与启发--《代码整洁之道》总结注释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字大一学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值。

代码整洁之道读后感
使⽤常亮来代表代码中的各种状态
例如如下代码 B代码要更具有可读性
A
if task_obj.task_template.type == 1:
do_something()
B
if task_obj.task_template.type == NORMAL_MODEL:
do_something()
⼀个函数只做⼀件事情，⼀个函数集成太多功能会带来以下问题
可读性变差，不好理解函数到底是做什么的，因为这往往集聚了太多的功能。

如果⼀个函数是⼀由很多⼩的单元租出的，你往往能够通过这些⼩单元的名字来推测出来这个函数的功能。

这也再次说明了，函数命名和变量的命名的⾮常重要
可维护性变差，带代码出现bug的时候⾮常难以定位问题，你很难在⼀⼤串代码中定位是哪个代码出了问题。

⼀个函数下，应该包含同⼀层抽象的函数。

注释尽量不需要，与其想注释，不如思考如何让变量名字更加通俗易懂
变量名字：
⼀个相关系统的变量应该⾜够的相关，例如
food_category
food_menu
food_library
同⼀个概念不要使⽤难以区分的近义词
例如 food_ticket, meal_ticket 类似看不出区别的变量。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

代码整洁之道-第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.类.....................................................................................................................................109.1类的组织 (10)9.2类应该短小.........................................................................................................10."其他章节 (10)1.本书内容概要核心观点：Bob大叔（即Robort.C.Martin，多本畅销书的作者，业界称其Bob大叔）认为软件质量，不仅依赖于架构及项目管理，而且与代码质量紧密相关。

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

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

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

代码整洁之道-第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_'前缀来表明成员变量•接口和实现别在名称中编码。

《代码整洁之道》笔记之函数作者给出了⼏个评判函数好坏的标准：短⼩作者给的函数合理长度是⼩于15⾏，⽬标是每个函数都⼀⽬了然，每个函数都会把你依次带到下⼀个函数中去。

if、else、while语句等其中的代码快应该只有⼀⾏。

该⾏⼤抵应该是⼀个函数的调⽤语句。

这样不但能保持函数短⼩，⽽且因为块内调⽤的函数拥有较具说明⾏的名称，从⽽增加了⽂档上的价值函数的缩进曾不该多余两层，这样函数更容易理解。

只做⼀件事从我接触编程开始，这条规则反反复复听了很多遍：函数应该做⼀件事，做好这件事，只做这⼀件事。

问题是那件事是什么，函数到底做了⼀件事还是做了⼏件事。

⽐如⼀个名为write_text_to_file(char *filename)的函数，它在其中会打开⼀个⽂件，写⼊⽂本到这个⽂件，然后关闭⽂件流。

这算⼏件事？作者如是说：如果函数只是做了该函数名下同⼀抽象层上的步骤，则函数还是只做了⼀件事。

这样就好分辨的多。

我的理解是：write_text_to_file函数⾥⾯调⽤的⼏个函数，fopen、fwrite、fclose都是同⼀抽象层的，这算是只做了⼀件事，如果调⽤了更上层的delete_file函数，这样就算两件事了。

不知道这样理解有没错。

switch语句的正确使⽤学习过《windows程序设计》的⼈肯定都写过这样的代码：switch(uMsg){case WM_DESTORY://xxxxxxxbreak;case WM_CREATE://xxxxxxxbreak;}在其中对WINDOWS窗⼝的消息进⾏判断，然后处理。

没什么封装的话，就是直接写在case和break之间，⼀⼤坨。

有了点封装，会把要执⾏的代码写到独⽴的函数⾥，在收到消息时进⾏调⽤。

还可以弄个消息表，这样只需要在for循环中就完成了对应消息的处理，除⾮是写框架时才会这么做，⼀般都没这么多消息要处理。

有了⾯向对象还可以利⽤继承和多态机制来简化代码，参看：作者这么说switch：对于switch语句，我的规矩是如果只出现⼀次，⽤于创建多态对象，⽽且隐藏在某个继承关系中，在系统其他部分看不到，就能容忍对于switch他也没说绝对，后来⼜补充说：要就事论事函数的名称函数名别怕长，命名⽅式要在模块中进⾏统⼀。

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

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

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

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

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

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

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

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

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

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

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

2. 使用代码注释作者。

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

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

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

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

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

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

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

4. 标注重点。

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

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

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

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

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

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

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

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

代码整洁之道读书笔记-第4章注释只有代码能告诉你它做的事，那是唯⼀真正准确的信息来源。

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

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

有些注释是必须的，也是有利的。

不过要记住，唯⼀真正好的注释是想办法不去写的注释1、法律信息// Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.// Released under the terms of the GNU General Public License version 2 or later.公司代码规范要求编写与法律有关的注释。

2、提供信息的注释//Returns an instance of the Responder being tested.protected abstact Responder responderInstance();这类注释有时管⽤，但是更好的⽅式是尽量利⽤函数名称传达信息。

⽐如，把函数重命名为responderBeingTested。

3、对意图的解释//we are greater because we are the right type.//This is our best attempt to get a race condition by creating large number of threads.不仅提供了有关实现的有⽤信息，⽽且还提供了某个决定后⾯的意图。

4、阐释assertTrue(pareTo(a) == 0); //a == aassertTrue(pareTo(b) != 0); //a != bassertTrue(pareTo(ab) == 0); //ab == abassertTrue(pareTo(b) == -1); //a < bassertTrue(pareTo(ab) == -1); //aa < abassertTrue(pareTo(bb) == -1); //ba < bbassertTrue(pareTo(a) == 1); //b > aassertTrue(pareTo(aa) == 0); //a == aassertTrue(pareTo(ba) == 0); //a == a把某些晦涩难明的参数或返回值的意义翻译为某种可读形式。

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

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

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

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

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

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

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

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

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

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

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

整洁的代码只做好一件事”，即：“优雅”和“效率”; Grady 的观点与 Bjarne 类似“整洁的代码简单直接。