write solid code 零散（原文）

整理下目录，看了这个文件，幸好未删除。

以下是《write solid code》中的原文摘录。

1、How could I have prevented this bug?

2、How could I have automatically detected this bug?

3、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.

4、Having a good set of habits and attitudes is possibly the most important requirement for consistently writing bug-free code.

5、The developers can bring more knowledge and tools to reviewing and testing the code.

6、Finding and fixing bugs was Developments's responsibility.

7、If you find undefined behavior, either remove it from the design or include assertions to notify programmers when they use undefined behavior.
     Don't waste people's time. Document unclear assertions.

8、Once you've written a function, review it and ask yourself, "What am I assuming?" If you find an assumption, either assert that your assumption is always valid, or rewrite the code to remove the assumption. Also ask, "What is most likely to be wrong in this code, and how can I automatically detect the problem?" Strive to implement tests that catch bugs at the earliest possible moment.

9、The purpose of the debug version is to catch bugs, not to make the maximal use of memory.

10、You don't save time by fixing bugs late in the product cycle. In fact, you lose time because it's often harder to fix bugs in code you wrote a year ago than in code you wrote days ago;

11、Fixing bugs "as you go" provides damage control because the earlier you learn of your mistakes, the less likely you are to repeat those mistakes;

12、Bugs are a form of negative feedback that keep fast but sloppy programmers in check. If you don't allow programmers to work on new features until they have fixed all their bugs, you prevent sloppy programmers from spreading half-implemented features throughout the product----they're too fixing bugs. If you allow programmers to ignore their bugs, you lose that regulation.

13、By keeping that bug count near zero, you have a much easier time predicting when you'll finish the product. Instead of trying to guess how long it will take to finish 32 features and 1742 bug-fixes, you just have to guess how long it will take to finish the 32 features. Even better, you're often in a position to drop the unfinished features and ship what you have.