Clean Code

Robert C. Martin

出版社

Prentice Hall

出版时间

2008-08-11

ISBN

9780132350884

评分

★★★★★
书籍介绍
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way. Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it. What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code. Readers will come away from this book understanding How to tell the difference between good and bad code How to write good code and how to transform bad code into good code How to create good names, good functions, good objects, and good classes How to format code for maximum readability How to implement complete error handling without obscuring code logic How to unit test and practice test-driven development This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
AI导读
核心看点
  • 提出WTF/min衡量代码质量,倡导整洁代码准则
  • 详解命名、函数、注释、格式等编程最佳实践
  • 强调测试代码与生产代码同等重要,需保持整洁
适合谁读
  • 希望提升代码质量与可维护性的软件开发者
  • 追求工匠精神、渴望成为专业程序员的工程师
  • 从事敏捷开发及团队协作的软件开发人员
读前提醒
  • 书中原则看似基础,实际践行难度极高,需反思
  • 部分观点具主观性,建议结合团队规范灵活应用
  • 英文原版表达更精准,建议对照阅读以避歧义
读者共识
  • 程序员必读经典,尽早阅读可节省大量维护时间
  • 核心在于为后续阅读者减轻认知负荷,提升效率
  • 道理虽浅显易懂,但真正落实需长期刻意练习

本导读基于书籍简介、目录、原文摘录、短评和书评生成,不等同于全文精读。

精彩摘录
  • "衡量代码质量的唯一有效标准: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. “Uncle Bob” Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.
用户评论
verbose
一个有故事的老男人
和同组同事在周会上读了一年多的书。觉得书中原则可简化成「为之后阅读/修改代码的自己或他人减轻认知负荷」。
醍醐灌顶,每一个程序猿都应该尽早读的一本书,早一天读也就少一天浪费他人和自己的生命了~
Aweshhome!
这如同与前辈关于代码可阅读性的一场谈话。不敢保证我同意书里的每一句话,但本书提供了一个senior&experienced的视角看待代码,这让我受益良多
老外程序员真的敬业,不放过任何细节。读了一遍,感觉还是需要大量实践才能真正理解里面的精髓
自从读完clean code,看见旧代码就想重构(不是
刚开始写代码的时候读很有用
后面几章java味太冲了直接过了. 前面几章讲的太好了, 给了非常有用的原则. 比如函数应该只做一件事, 参数不要太多, 尽量不用swtich(如果一定要用, 最好只出现一次, 比如factory pattern create object的时候); talk to friends, not to strangers (不要x.foo().bar()这样); 用exception代替error code, 不要返回null, 也不要传null, 考虑使用一个特殊值代替(比如python可以考虑返回空数组[], cxx17可以用std::optional); 用第三方代码, 不要直接call raw api, 最好写一个adapter, 这样对方更新了代码对自己影响小;一定要写unittest
收藏