《代码大全2》读书笔记二

第7章 高质量的子程序（High-Quality Routinges）
复杂的布尔判断，应该使用子程序来实现。

人类很难同时记住超过7个单位的信息。

子程序的名字是它的质量的指示器。如果名字糟糕但恰如其分，那说明这个子程序设计得很差劲。如果名字糟糕而且又不准确，那么它就反映不出程序是干什么的。不管怎样，糟糕的名字都意味着程序需要修改。

第8章 防御式编程（Defensive Programming）
保护程序免遭非法输入数据的破坏。检查所有来源于外部的数据的值。

用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。

可以让软件的某些部分（某个抽象层，公用方法等）处理“不干净的”数据，而让另一些部分处理“干净的”数据，即可让大部分代码无须再担负检查错误数据的职责。

异常

用异常通知程序的其他部分，发生了不可忽略的错误。在恰当的抽象层次抛出恰当的异常，比如底层异常不应该在高层抽象中被抛出。

第3部分 变量
第10章 使用变量的一般事项（General Issues in Using Avriables）
初始化

在声明变量的时候初始化。

理想情况下，在靠近第一次使用变量的位置声明和定义改变量。

在可能的情况下使用final或者const。

作用域

使变量的引用局部化，减小变量的作用域：

在循环开始之前再去初始化该循环里使用的变量，而不是在该循环所属的子程序的开始处初始化这些变量。

直到变量即将被使用时再为其赋值。

把相关语句放在一起，可能的情况下提取成单独的子程序。

开始时采用最严格的可见性（比如设为private），然后根据需要扩展变量的作用域。

“方便性”和“智力可管理性”两种理念之间的区别，归根结底来源于侧重写程序还是读程序之间的区别。

每个变量只应该用于单一用途，且不应该有隐藏含义（比如当x大于5000时代表什么）。

第11章 变量名的力量（The Power of Variable Names）
通常，对变量的描述就是最好的变量名。名字对于代码读者的意义要比对作者更重要。

一个好名字通常表达的是“what”而不是“how”。一般而言，如果一个名字反映了计算的某些方面而不是问题本身，那么它反映的就是“how”而不是“what”了。

较长的名字适用于较长的作用域，较短的名字适用于短的作用域（循环、小的方法等）。

计算限定词，如Total、Sum、Average、Min、Max、String、Pointer等等，应该放在名字的最后。

典型的布尔变量名：done, error, found, success, ok等。布尔变量应该是那些隐含了“真/假”含义的名字，如done和success等。应该使用肯定的布尔变量命名，而不是notFound，notDone等。

枚举类型要有统一的组前缀。

避免使用具有相似含义的名字。如果你能够交换两个变量的名字而不会妨碍对程序的理解，那么你就需要为这两个变量重新命名了。

命名规则应该能够区分局部数据、类的数据和全局数据。