读书笔记 摘自：《程序员修炼之道》
30. 你不可能写出完美的软件
You Can’t Write Perfect Software
软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。
21 按合约设计
31. 通过合约进行设计
Design with Contracts
使用合约建立文档，并检查代码所做的事情正好是他声明要做的。
在写函数的时候，入口处 assert输入参数，出口处返回该调用是否成功是最基本的。只是我们没有比较正式的将其称为前条件、后条件并注释出来。当然，也会在入口，出口处检查某个状态是否成立，这应该就是这里指的”不变项”。我想，明确这些概念，可以让我们在写代码的时候有比较清晰的思路来保证函数的规范性。实现一个函数的时候先思考一下，它的合约是什么呢~~~
22 死程序不说谎
32. 早崩溃
Crash Early
死程序造成的危害通常比有问题的程序要小的多。
尽早检测问题的好处之一是你可以更早崩溃
当程序中有致命错误时，直接crash会是比较好的选择。因为这样是以最明确的方式报告了错误，便于修正。如果试图掩盖这种错误，虽然程序还是运行着，却有着潜在的危险。比如C++中两次迭代的异常会导致程序crash，如果你试图在析构函数中吞下第二个异常，其实是掩盖了错误，而不是解决了问题。
与其苟延残喘的活着，不如给他痛痛快快的来一刀吧!
23 断言式编程
33. 如果它不可能发生，用断言确保它不会发生
If It Can’t Happen, Use Assertions to Ensure That It Won’t
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
断言检查的是决不应该发生的事情。
检查任何可能的错误；使用断言设法检测你疏漏的错误。
即使确实有性能问题，也只关闭那些真的有很大影响的断言。
这是防御式编程的重要组成部分，如果你觉得”不可能”发生，那就用断言确保它不会发生。当然，注意这里是”不可能”发生，很多初学者很容易认为在失败的时候就assert，比如流程：为打开一个文件，如果不存在，则先创建它。那么在第一步打开文件失败时，很多人会错误的使用一个 assert，而其实，这是”可能”的情况。
24 何时使用异常
34. 将异常用于异常问题
Use Exceptions for Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
异常应该留给意外事件。
对于错误处理的方式，异常处理比返回值判断的好处在于：减少了条件判断；把错误处理的代码集中到了一起。但是我们工作中用的最多的，还是返回值处理。
在异常处理中，一个很重要的措施是保证异常抛出时，资源能被正确的释放掉，在C++中，我们可以用RAII，而在C#，或者Java中，我们可以利用finally语句。
25 怎样配平资源
35. 要有始有终
Finish What You Start
只要可能，分配某资源的例程或对象也应该负责解除其分配。
管理资源：内存、事物、线程、文件、定时器
关于资源管理的章节
几个原则吧：
1. 谁分配谁释放
2. 先分配的后释放 — 以防后分配的对先分配的有引用
3. 在代码不同的地方以相同次序分配资源 — 避免死锁
当接触顶层结构的分配时
１.顶层结构还负责释放它包含的任何子结构。这些结构随机递归地删除它们包含的数据，等等。
２.只是解除顶层结构的分配。它指向的（没有在别处引用的）任何结构都会被遗弃。
３.如果顶层结构含有任何子结构，它就拒绝解除自身的分配。
部分评论摘自豆瓣书评
===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用*转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://my.csdn.net/dkjkls