![代码整洁之道 - [美]Robert C. Martin](https://static.book345.com/covers/9787115216878.jpg)
书籍介绍
软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。
本书提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，本书作者给出了一系列行之有效的整洁代码操作实践。这些实践在本书中体现为一条条规则（或称“启示”），并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。
本书阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。
AI导读
核心看点
- 提出代码整洁度与质量正比，童子军军规倡导代码越写越干净
- 详解命名、函数、注释等实操规则，如函数短小且只做一件事
- 强调代码即文档，通过正反面范例展示如何编写易维护代码
适合谁读
- 有志于改善代码质量，追求编程艺术的专业程序员
- 需要规范团队代码风格，提升软件可维护性的技术经理
- 具备一定基础，希望从细节入手进阶的中高级开发者
读前提醒
- 书中规则基于作者经验，需结合具体语言特性灵活变通
- 部分规则如函数行数限制较严格，建议审慎思考后采纳
- 前半部分干货密集，后半部分略显平淡，可重点阅读前章
读者共识
- 公认的经典之作，对代码细节的关注能立竿见影提升质量
- 写代码犹如写文章，整洁代码让缺陷难以隐藏且易于阅读
- 虽翻译略有瑕疵且部分观点显教条，但核心思想极具价值
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "衡量代码质量的唯一有效标准：WTF/min"
- "1，代码逻辑直接了当，让缺陷难以隐藏 2，尽量减少依赖关系，使之便于维护 3，依据某种分层策略完善错误处理代码 4，性能调至最优，省得引诱别人做没规矩的优化 5，整洁的代码只做一件事 6，简单直接，具有可读性 7，有单元测试和验收测试 8，有意义的命名 9，代码应在字面上表达其含义 10，尽量少的实体：类、方法、函数 11，没有重复代码"
- "1，名副其实：名称不需要注释补充就可见其含义、用途 2，避免误导： （1）系统专有名称不宜作为变量名 （2）提防差别很小的名称，在代码自动完成时容易选错 （3）用字母I和O作为变量名，让人看成1和0 3，做有意义的区分 不要用数字或废话来区分 4，使用读得出来的名称 5，使用可搜索的名称 少用单字母名称或没有名称的数字常量 6，避免使用编码 （1）不必在名称中标明类型，现代语言有完善的类型检查 （2）不必在名称中区别成员变量，应采用自动高亮成员的编译环境 （3）宁可对实现编码，也不要对接口编码 7，避免使用让别人理解成其他领域常用词的名称 8，类名应该是名词或名词短语，不应是动词 9，方法名应"
- "1，短小 （1）不该超过20行 （2）每个代码块（if， else，while）应该只有一行，包含一个函数 2，只做一件事 如果能拆成几个函数，就不是只做一件事 3，每个函数一个抽象层次 自顶向下的抽象层次 4，switch语句 用于创建多态对象，并隐藏在抽象工厂中 5，使用描述性的名称 6，尽量避免多余2个参数 （1）使用返回值而不是输出参数 （2）不要用标识参数，即向函数传入bool值，应该写成两个函数 （3）如果一定需要多个参数，那么可能需要对参数进行封装 7，无副作用 尽量少做不是函数名称表明的事情 8，使用异常代替返回错误码 （1）把try，catch从正常流程中分离开 9，消除重复"
- "1，尽量减少注释量，用代码本身说明问题 （1）代码常常变动，注释却不能跟着变 （2）只有代码是唯一准确的信息来源 （3）创建一个和注释所言相同的函数来代替注释 2，好的注释 （1）法律信息 （2）解释程序员的意图 （3）警示其他程序员某种后果 （4）TODO 定期删除不需要的 （5）公共API中的javadoc 3，坏的注释 （1）喃喃自语，只有作者自己能看懂 （2）多余的注释 不一定比代码精到 （3）不是每个函数和变量都要有javadoc （4）日志式注释，修改记录 （5）能用函数或变量时就别用注释 （6）用代码控制系统，而不是注释表明归属 （7）不要保留注释掉的代码，利用源代码控制系统"
- "1，垂直距离 （1）变量声明尽可能靠近使用位置，本地变量应在函数顶部出现 （2）实体变量应在类的顶部声明 （3）相关函数放在一起 （4）函数的排列顺序保持其相互调用的顺序 2，水平位置 （1）一行代码尽量短，不超过100-120字符 （2）用空格将相关性弱的分开：加减法，赋值，乘法因子见无需空格 （3）声明和赋值不需要水平对齐 （4）缩进 空循环容易忽略行末的分号，要括号包围空循环。"
- "1，TDD三定律 （1）在编写不能通过的单元测试前，不能编写生产代码 （2）只可编写刚好无法通过的单元测试，不能编译也不算通过 （3）只可编写刚好足以通过当前失败测试的生产代码 2，测试代码和生产代码一样重要，一样需要整洁 3，每个测试一个断言，每个测试一个概念"
- "1，并发防御原则 （1）单一权责：方法/类/组件应当只有一个修改的理由 （2）限制数据作用域 （3）使用数据副本避免共享数据 （4）线程应尽可能独立 2，了解常见的执行模型：生产者-消费者，读者-作者，宴席哲学家 3，警惕同步方法之间的依赖 4，保持同步区微小 5，尽早考虑关闭的代码，注意线程之间的依赖关系 6，测试线程代码 （1）将伪失败看作可能的线程问题 （2）先使非线程代码工作 （3）运行多于处理器数量的线程 （4）在不同平台上运行 （5）手动插入调试的试错代码"
作者简介
Robert C. Martin，Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域的资深顾问。他是Designing Object-Oriented C++ Applications Using the Booch Method及Jolt获奖图书Agile Software Development, Principles, Patterns, and Practices（中译版《敏捷软件开发：原则、模式与实践》）等畅销书作者。
目录
用户评论
虽然页码注水，但是前十几章就已经值回票价，比重构更对我胃口
有原则的实操指导。所谓魔鬼在细节中，当然你先得有一颗琢磨细节魔鬼的匠心。
不错，都从细节中来。但是细节中蕴含着追求效率，完美架构，简易维护的精神和道理。
1.很细致周到，作者用心良苦。本书写了作者的经验之谈，很多都值得学习，但也不能盲目轻信，审慎思考很重要。非常适合有一定经验的新手来看，非常有启示性。 2.总觉得韩磊的译笔太酸了…“窃以为”这是何必呢...造句通顺，但遣词仍需改进。
参数尽量少，函数抽象层级
是技术人的童话书还是操作指南？在屎山里挣扎的时候可以看看，让信念坚定一点儿。
其中很多很多的技巧，规范，都非常非常有用，并且在最近的工作中也立刻就用到了。但是这不是一蹴而就的事情，还需要不断的磨炼。
好棒，适合新手看。没时间看最后一章就好了，但是前几章的案例很棒。看完特别想去大扫除… 套how to take good note 之言，写作的不同层次是不同任务，每一只完成一种任务，比较省精力。 代码也是一样。总结一下：编程是种语言，可以用写作的方法对待它（初稿，再稿修改逻辑顺序，选择用词，润色，test)
2. 编程是种语言，尽量不要用别的语言来注释它（例如英语，大部分要注释的情况是名字没取好）
在公司没事看看竟然看完了，前半部分在讲一些比较general的经验和规范，还是有所收获的；后面大篇幅讲并发编程相关，但讲的比较浅显。需要另一本书Brian Goetz的java concurrency in practice 来系统学习
光速刷了一遍，前五章看了还有点收获。
总的来说不是很推荐……涉及到了单元测试和并发编程，但就类似抛砖引玉，还得自己去看其他书比较好。至于迭代、设计之类的章节，不知道是翻译的问题还是我的水平不够，感觉看起来也没啥太大收获，大几百页的，感觉收获还没Java开发手册多= =
下载
收藏