<<Writing Solid Code>> - by Steve Maguire, 1993.
编写可靠的/健壮的/没有bug的代码

【注】虽然书中很多例子是基于C语言的，但是编程的思想是相通的，而且书中提出的解决问题的方法及原理是语言无关的。这本书是由多条指导方针组成的，正如作者所说，这些指导方针是多年长期思考及实践的结果，指导方针看似简单，却是经验的总结。除次之外，书中对于解决问题的思考过程显得尤为珍贵。

以下摘取每章的概述以及每条指导方针，附翻译及简单注释。
－－－－－－－－－－－－
Introduction
－－－－－－－－－－－－

Summary:
With the growing complexity of software and the associated climb in bug rates, it's becoming increasingly necessary for programmers to produce
bug-free code much earlier in the development cycle, before the code is first sent to Testing. The key to writing bug-free code is to become more
aware of how bugs come about. Programmers can cultivate this awareness by asking themselves two simple questions about every bug they encounter:
"How could I have prevented this bug?" and "How could I have automatically detected this bug?" The guidelines in this book are the results of regularly asking these two questions over a number of years.

概述：
随着软件复杂性的增长以及相应的bug发生率的爬升，对于程序员来说，在开发周期中代码拿去测试之前，更早地编写bug-free代码变得更加必要。编写bug-free代码的关键是意识到bugs是怎样出现的。程序员能够通过问他们自己关于遇到的每个bug这样两个问题来培养这个技能。

1.我怎样才能阻止这个bug发生？
2.我怎样才能自动察觉到这个bug？

这本书中的指导方针就是多年规律性地问这两个问题的结果。

－－－－－－－－－－－－－－－－－－－－
Chapter 1 A Hypothetical Compiler
一个假定的编译器
－－－－－－－－－－－－－－－－－－－－
Summary:
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.

概述：
如果你的编译器能够察觉到程序中每个bug ，无论是什么类型，并且还发出一个错误消息，那么让你的代码规避bugs就是简单的事情。这样无所不知的编译器是不存在的，但是通过开启可选的编译器警告选项，使用语法以及可移植性检查器，以及使用单元测试，被你自动察觉到的bugs数目就会增加。

Guidelines:
1.1.Enable all optional compiler warnings.
开启所有可选的编译器警告选项。

1.2.Use lint to catch bugs that your compiler may miss.
使用lint来抓住那些编译器可能遗漏的bugs。

【注】lint是一种代码质量保证工具，能够进行更强的编译检查。如：pc-lint。在有些公司，在check in代码到main branch之前，一般需要通过lint检查，当然最好也开启lint的所有警告开关，久而久之，不需要工具辅助，也能写出健壮的代码。

1.3.If you have unit tests, use them.
如果有单元测试，使用他们。

【注】程序员所做的单元测试侧重于验证代码内部结构和处理过程，大部分利用白盒测试手段，比如设计一些用例测试其内部的逻辑，象控制点（如：条件判断点，循环点，选择分支点等），比如检查内部数据的有效性，甚至检查代码的冗余等。仅仅依赖于黑盒测试是不够的。

－－－－－－－－－－－－－－－－－－－－－－－－－－
Chapter  2 Assert Yourself
断言你自己
－－－－－－－－－－－－－－－－－－－－－－－－－－－
Summary:
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.

概述：
一个好的开发策略是维护两套版本的程序，一个用来发布一个用来调试。通过使用调试断言语句，你可以察觉到由非法的函数参数，未定义行为的意外使用，其他程序员的错误的假设以及不可能发生的情况仍然不知何故出现了所造成的bugs。只用于调试的备份算法能帮助验证函数的结果以及函数中使用的算法。

Guidelines:
2.1.Maintain both ship and debug versions of your program.
维护发布和调试两套版本的程序

2.2.Use assertions to validate function arguments
使用断言来验证函数参数

【注】常见的使用Assert的一个地方。在入口处检查参数，及早发现问题，使用Assert的好处是在调试版本下能立刻定位到上下文。

2.3.Strip undefined behavior from your code, or use assertions to catch illegal uses of undefined behavior.
去除代码中的未定义的行为，或者使用断言来抓住未定义行为的非法使用。

【注】使用Assert的又一个地方。作者举了个c实现内存拷贝的例子，当在两块重叠的内存之间进行拷贝的时候的行为是未定义的。所以加上个Assert来断言传入的两个指针所指内存之间足够大。

2.4.Don't waste people's time. Document unclear assertions.
不要浪费人们的时间。为不清楚的断言加上说明

2.5.Either remove implicit assumptions, or assert that they are valid.
要么消除隐式的假设，要么断言它们是合法的。

【注】使用Assert的又一个地方。作者举了个c实现内存设值的例子，有时为了加快memset，会将byte*指针转换成long*的。但是byte*的指针可能是个奇地址，如果转换成long*的，在有些系统上会出问题，因为long*的指针在这些系统上不能以奇地址开始。

2.6.Use assertions to detect impossible conditions.
使用断言来察觉不可能的情况。

2.7.Don't hide bugs when you program defensively.
在进行防御式编程时，不要隐藏bugs。
【注】防御式编程是一种编程风格，主要目的是保护系统不受“非法”输入的破坏，但这样很容易掩盖bugs。

2.8.Use a second algorithm to validate your results.
使用第二套算法来验证你的结果。

2.9.Don't wait for bugs to happen; use startup checks.
不要等着bugs发生，使用启动检查。

to be continued...