基本信息出版社：人民邮电出版社
页码：256 页
出版日期：2009年02月
ISBN：7115193169/9787115193162
条形码：9787115193162
版本：第1版
装帧：平装
开本：16
正文语种：英语
丛书名：图灵程序设计丛书

内容简介 《编程精粹编写高质量C语言代码》(英文版)：软件日趋复杂，编码错误随之而来。要在测试前发现程序的错误，开发出无错误的程序，关键是弄清楚错误为何产生，又是如何产生。《编程精粹编写高质量C语言代码》给出了多条编程方面的指导，这些指导看似简单，却是作者多年思考及实践的结果，是对其编程经验的总结。书中解决问题的思考过程对于程序开发人员尤显珍贵。
媒体推荐 “本书所蕴含的思想精髓可以说是不朽的，它彻底改变了我的编程方式。”
　　——David Kline，微软资深工程师，.NET Compact Framework核心开发成员
“如果你想成为真正的C程序员，如果你想打造真正优秀的软件开发团队，请读本书。不要找什么借口去忽视它，是十足的愚蠢之举，蜂拥而至的bug会很快来惩罚你。”
　　——ACCU（C/C++用户协会）网站
编辑推荐 《编程精粹编写高质量C语言代码》(英文版)揭示了微软公司应对质量挑战、开发出世界级代码的技术内幕，作者在自己不断探索、实践和思考的基础上，系统总结了多年来指导微软各团队的经验，将其凝聚为许多切实可行的编程实践指导，可谓字字珠玑。正因如此，《编程精粹编写高质量C语言代码》被公认为与《代码大全》齐名的编程技术名著，曾于1993年荣获有软件开发奥斯卡奖之称的Jolt生产效率大奖。书中内容主要针对C语言，但其中的思想对目前的各主流语言编程也完全适用。
编写高质量的、没有bug的程序，是每位程序员所追求的目标。但随着软件规模越来越大，功能日趋复杂，这一目标变得越来越困难。
Stephen A．Maguire，世界著名的技术专家和技术作家。曾在微软公司供职多年，领导开发了Mac版的Excel和众多重要的跨平台项目，并多次扮演救火队员的角色，成功拯救那些陷入困境的团队。现为Web开发公司Storm Development的高级副总裁。他的另一部名著Debugging the Development Process继《编程精粹编写高质量C语言代码》之后第二年再次摘得Jolt生产效率大奖，成为空前绝后的传奇。
与《代码大全》齐名的经典著作
提示微软成功的技术奥秘
C语言高手的秘籍
《编程精粹编写高质量C语言代码》(英文版)适于各层次程序开发人员阅读。
目录
1 A HYPOTHETICAL COMPILER .
If your compiler could detect every bug in your program——no matter the type——and issue an error message, ridding your code of bugs would be simple. Such omniscient compilers don't exist, but by enabling optional compiler warnings, using syntax and portability checkers, and using automated unit tests, you can increase the number of bugs that are detected for you automatically.

2 ASSERT YOURSELF
A good development strategy is to maintain two versions of your program: one that you ship and one that you use to debug the code. By using debugging assertion statements, you can detect bugs caused by bad function arguments, accidental use of undefined behavior, mistaken assumptions made by other programmers, and impossible conditions that nevertheless somehow show up. Debug-only backup algorithms help verify function results and the algorithms used in functions.

3 FORTIFY YOUR SUBSYSTEMS
Assertions wait quietly until bugs show up. Even more powerful are subsystem integrity checks that actively validate subsystems and alert you to bugs before the bugs affect the program. The integrity checks for the standard C memory manager can detect dangling pointers, lost memory blocks, and illegal use of memory that has not been initialized or that has already been released. Integrity checks can also be used to eliminate rare behavior, which is responsible for untested scenarios, and to force subsystem bugs to be reproducible so that they can be tracked down and fixed.

4 STEP THROUGH YOUR CODE
The best way to find bugs is to step through all new code in a debugger. By stepping through each instruction with your focus on the data flow, you can quickly detect problems in your expressions and algorithms. Keeping the focus on the data, not the instructions, gives you a second, very different, view of the code. Stepping through code takes time, but not nearly as much as most programmers would expect it to.

5 CANDY-MACHINE INTERFACES
It's not enough that your functions be bug-free; functions must be easy to use without introducing unexpected bugs. If bug rates are to be reduced, each function needs to have one well-defined purpose, to have explicit single-purpose inputs and outputs, to be readable at the point where it is called, and ideally to never return an error condition. Functions with these attributes are easy to validate using assertions and debug code, and they minimize the amount of error handling code that must be written.

6 RISKY BUSINESS
Given the numerous implementation possibilities for a given function, it should come as no surprise that some implementations will be more errorprone than others. The key to writing robust functions is to exchange risky algorithms and language idioms for alternatives that have proven to be comparably efficient yet much safer. At one extreme this can mean using unambiguous data types; at the other it can mean tossing out an entire design simply because it would be difficult, or impossible, to test.

7 TREACHERIES OF THE TRADE
Some programming practices are so risky they should never be used. Most such practices are obviously risky, but some seem quite safe, even desirable, because they fill a need without apparent hazard. These treacherous coding practices are the wolves in sheep's clothing. Why shouldn't you reference memory you've just released? Why is it risky to pass data in global or static storage? Why should you avoid parasitic functions? Why it is unwise to rely on every nit-picky detail outlined in the ANSI standard?

8 THE REST IS ATTITUDE
A programmer can follow every guidcline in this book, but without the proper attitude and a set of good programming habits, writing bug-free code will be much harder than it needs to be. If a programmer believes that a bug can simply "go away," or that fixing bugs "later" won't be harmful to the product, bugs will persist, ff a programmer regularly "cleans up" code, allows unnecessary flexibility in functions, welcomes every "free" feature that pops out of a design, or simply "tries" haphazard solutions to problems hoping to hit upon something that works, writing bug-free code will be an uphill battle. Having a good set of habits and attitudes is possibly the most important requirement for consistently writing bug-free code.
EPILOGUE WHERE DO YOU GO FROM HERE?
APPENDIX A CODING CHECKLISTS
APPENDIX B MEMORY LOGGING ROUTINES
APPENDIX C ANSWERS
REFERENCES
INDEX
……
序言 In 1986, after 10 years of consulting and working for small companies, I went to work for Microsoft specifically to get experience in writing Macintosh applications. I joined Microsoft's Excel team, the group responsible for the company's graphical spread
文摘 插图：