第7章 高质量的子程序
复杂的布尔判断，应该使用子程序来实现。
人类很难同时记住超过7个单位的信息。
子程序的名字是它的质量的指示器。如果名字糟糕但恰如其分，那说明这个子程序设计得很差劲。如果名字糟糕而且又不准确，那么它就反映不出程序是干什么的。不管怎样，糟糕的名字都意味着程序需要修改。
第8章 防御式编程
保护程序免遭非法输入数据的破坏。检查所有来源于外部的数据的值。
用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。
可以让软件的某些部分（某个抽象层，公用方法等）处理“不干净的”数据，而让另一些部分处理“干净的”数据，即可让大部分代码无须再担负检查错误数据的职责。
异常
用异常通知程序的其他部分，发生了不可忽略的错误。在恰当的抽象层次抛出恰当的异常，比如底层异常不应该在高层抽象中被抛出。
第10章 使用变量的一般事项
初始化
在声明变量的时候初始化。
理想情况下，在靠近第一次使用变量的位置声明和定义改变量。
在可能的情况下使用final或者const。
作用域
使变量的引用局部化，减小变量的作用域：
在循环开始之前再去初始化该循环里使用的变量，而不是在该循环所属的子程序的开始处初始化这些变量。
直到变量即将被使用时再为其赋值。
把相关语句放在一起，可能的情况下提取成单独的子程序。
开始时采用最严格的可见性（比如设为private），然后根据需要扩展变量的作用域。
“方便性”和“智力可管理性”两种理念之间的区别，归根结底来源于侧重写程序还是读程序之间的区别。
每个变量只应该用于单一用途，且不应该有隐藏含义（比如当x大于5000时代表什么）。
第11章 变量名的力量
通常，对变量的描述就是最好的变量名。名字对于代码读者的意义要比对作者更重要。
一个好名字通常表达的是“what”而不是“how”。一般而言，如果一个名字反映了计算的某些方面而不是问题本身，那么它反映的就是“how”而不是“what”了。
较长的名字适用于较长的作用域，较短的名字适用于短的作用域（循环、小的方法等）。
计算限定词，如Total、Sum、Average、Min、Max、String、Pointer等等，应该放在名字的最后。
典型的布尔变量名：done, error, found, success, ok等。布尔变量应该是那些隐含了“真/假”含义的名字，如done和success等。应该使用肯定的布尔变量命名，而不是notFound，notDone等。
枚举类型要有统一的组前缀。
避免使用具有相似含义的名字。如果你能够交换两个变量的名字而不会妨碍对程序的理解，那么你就需要为这两个变量重新命名了。
命名规则应该能够区分局部数据、类的数据和全局数据。
标签：变量,作用域,代码,程序,名字,读书,应该,子程序,大全 From： https://www.cnblogs.com/tianminggeng/p/16937232.html