基本信息·出版社：人民邮电出版社 ·页码：431 页 ·出版日期：2009年08月 ·ISBN：7115210489/9787115210487 ·条形码：9787115210487 ·版本：第1版 · ...
| 商家名称 |
信用等级 |
购买信息 |
订购本书 |
|
|
 |
代码整洁之道(英文版) |
 |
|
|
代码整洁之道(英文版) |
|
基本信息·出版社：人民邮电出版社
·页码：431 页
·出版日期：2009年08月
·ISBN：7115210489/9787115210487
·条形码：9787115210487
·版本：第1版
·装帧：平装
·开本：16
·正文语种：英语
·丛书名：典藏原版书苑
内容简介 软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发流派还是传统开发流派，都不得不承认。《代码整洁之道(英文版)》提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者，《代码整洁之道(英文版)》作者给出了一系列行之有效的整洁代码操作实践。这些实践在《代码整洁之道(英文版)》中体现为一条条规则（或称“启示”），并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。《代码整洁之道(英文版)》阅读对象为一切有志于改善代码质量的程序员及技术经理。书中介绍的规则均来自作者多年的实践经验，涵盖从命名到重构的多个编程方面，虽为一“家”之言，然诚有可资借鉴的价值。
作者简介 RObert C．Ma rlin，(Bob大叔)自1970年进入软件行业，从1990年起成为国际软件咨询师。他是Object Mentor公司的创始人和总裁。Object Mentor：是由一群经验丰富的咨询师组成的公司，他们的客户遍及全世界。
业务涉及C++、．Java、C#、Ruby、面向对象、设计模式、UML、敏捷方法论和极限编程等领域。
编辑推荐 从《代码整洁之道(英文版)》中可以学到：
好代码和糟糕的代码之间的区别；
如何编写好代码。如何将糟糕的代码转化为好代码；
如何创建好名称、好函数、好对象和好类；
如何格式化代码以实现其可读性的最大化；
如何在不妨碍代码逻辑的前提下充分实现错误处理；
如何进行单元测试和测试驱动开发。
Robert C．Martin(Bob大叔)自1970进入软件行业。从1990年起成为国际软件咨询师。他是ObjectMentor公司的创始人和总裁。Object Mentor是由一群经验丰富的咨询师组成的公司，他们的客户遍及全世界。
业务涉及C++、Java、C＃、Ruby、面向对象、设计模式、UML、敏捷方法论和极限编程等领域。
尽管糟糕的代码也能运行，但如果代码不整洁，会使整个开发团队泥足深陷，写得不好的代码每年都要耗费难以计数的时间和资源。然而这种情况并非无法避免。
著名软件专家Robert C．Martin在《代码整洁之道(英文版)》中为你呈现出了革命性的视野。Martin携同Object Menlor公司的同事，从他们有关整洁代码的最佳敏捷实践中提炼出软件技艺的价值观，以飨读者，让你成为更优秀的程序员——只要你着手研读《代码整洁之道(英文版)》。
阅读《代码整洁之道(英文版)》需要你做些什么呢?你将阅读代码——大量代码。《代码整洁之道(英文版)》促使你思考代码中何谓正确，何谓错误。更重要的是。《代码整洁之道(英文版)》将促使你重新评估自己的专业价值观，以及对自己技艺的承诺。
目录 Chapter 1: Clean Code 1
There Will Be Code 2
Bad Code 3
The Total Cost of Owning a Mess 4
The Grand Redesign in the Sky 5
Attitude 5
The Primal Conundrum 6
The Art of Clean Code? 6
What Is Clean Code? 7
Schools of Thought 12
We Are Authors 13
The Boy Scout Rule 14
Prequel and Principles 15
Conclusion 15
Bibliography 15
Chapter 2: Meaningful Names 17
Introduction 17
Use Intention-Revealing Names 18
Avoid Disinformation 19
Make Meaningful Distinctions 20
Use Pronounceable Names 21
Use Searchable Names 22
Avoid Encodings 23
Hungarian Notation 23
Member Prexes 24
Interfaces and Implementations 24
Avoid Mental Mapping 25
Class Names 25
Method Names 25
Don't Be Cute 26
Pick One Word per Concept 26
Don't Pun 26
Use Solution Domain Names 27
Use Problem Domain Names 27
Add Meaningful Context 27
Don't Add Gratuitous Context 29
Final Words 30
Chapter 3: Functions 31
Small! 34
Blocks and Indenting 35
Do One Thing 35
Sections within Functions 36
One Level of Abstraction per Function 36
Reading Code from Top to Bottom: The Stepdown Rule 37
Switch Statements 37
Use Descriptive Names 39
Function Arguments 40
Common Monadic Forms 41
Flag Arguments 41
Dyadic Functions 42
Triads 42
Argument Objects 43
Argument Lists 43
Verbs and Keywords 43
Have No Side Effects 44
Output Arguments 45
Command Query Separation 45
Prefer Exceptions to Returning Error Codes 46
Extract Try/Catch Blocks 46
Error Handling Is One Thing 47
The Errorjava Dependency Magnet 47
Don't Repeat Yourself 48
Structured Programming 48
How Do You Write Functions Like This? 49
Conclusion 49
SetupTeardownIncluder 50
Bibliography 52
Chapter 4: Comments 53
Comments Do Not Make Up for Bad Code 55
Explain Yourself in Code 55
Good Comments 55
Legal Comments 55
Informative Comments 56
Explanation of Intent 56
Clarication 57
Warning of Consequences 58
TODO Comments 58
Amplication 59
Javadocs in Public APIs 59
Bad Comments 59
Mumbling 59
Redundant Comments 60
Misleading Comments 63
Mandated Comments 63
Journal Comments 63
Noise Comments 64
Scary Noise 66
Don't Use a Comment When You Can Use a Function or a Variable 67
Position Markers 67
Closing Brace Comments 67
Attributions and Bylines 68
Commented-Out Code 68
HTML Comments 69
Nonlocal Information 69
Too Much Information 70
Inobvious Connection 70
Function Headers 70
Javadocs in Nonpublic Code 71
Example 71
Bibliography 74
Chapter 5: Formatting 75
Chapter 6: Objects and Data Structures 93
Chapter 7: Error Handling 103
Chapter 8: Boundaries 113
Chapter 9: Unit Tests 121
Chapter 10: Classes 135
Chapter 11: Systems 153
Chapter 12: Emergence 171
Chapter 13: Concurrency 177
Chapter 14: Successive Renement 193
Chapter 15: JUnit Internals 251
Chapter 16: Refactoring SerialDate 267
Chapter 17: Smells and Heuristics 285
Appendix A:ConcurrencyⅡ
Appendix B:org.jfree.date.SerialDate
Appendix C:Cross References of Heuristics
Epilogue
Index
……
序言 你的代码在哪道门后面？你的团队或公司在哪道门后面？为什么会在那里？只是一次普通的代码复查，还是产品面世后才发现一连串严重问题？我们是否在战战兢兢地调试自己之前错以为没问题的代码？客户是否在流失？经理们是否把我们盯得如芒刺在背？当事态变得严重起来，如何保证我们在那道正确的门后做补救工作？答案是：技艺。
习艺之要有二：知和行。你应当习得有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌，通过刻苦实践掌握它。
我可以教你骑自行车的物理学原理。实际上，经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等，用一页写满方程式的纸就能说明白。有了这些方程式，我可以为你证明出骑车完全可行，而且还可以告诉你骑车所需的全部知识。即便如此，你在初次骑车时还是会跌倒在地。
文摘 插图：
