第14章 组织直线型代码（Organizing Straight-Line Code）
依赖关系必须清晰明显。通子程序名、程序参数等实现。
第15章 使用条件语句（Using Conditionals）
If-ElseIf-Else结构中，最后一个Else确保所有的情况都考虑到了。
Case语句的顺序：首先按照频率从高到低，频率一样按照字母排列。
第16章 控制循环（Controlling Loops）
使用带退出的循环，类似：
while True:
# do something
if some_condition:
break
# do something
把初始化代码紧放在循环前面。
在循环的开始处用continue进行判断。
一个循环只做一件事。如果用两个循环会导致效率地下，而使用一个循环很合适，那么就把代码写成两个循环，并注明可以把它们合并起来以提高效率，然后等测量数据显示程序的这一部分性能低下的时候再去合并它们。
避免出现依赖循环下标最终取值的代码。
小心那些有很多break散布其中的循环。一个循环包含很多的break，有可能意味着程序员对该循环的结构或者对循环本身的角色缺乏清晰的认识。在大量使用break的场合中，用一系列的循环而非一个含有多个出口的循环可能会使表达更清晰。
循环要尽可能短，嵌套限制在3层内。
第17章 不常见的控制结构（Unusual Control Structures）
子程序中的多处返回（Multiple Returns）：如果能增强可读性，那么就使用return。
小心谨慎地使用递归。
第18章 表驱动法（Table-Driven Methods）
使用一目了然的表来代替复杂的逻辑判断。
第19章 一般控制问题（General Control Issues）
Tips：
-
编写肯定形式的布尔表达式
-
按照数轴的顺序编写数值表达式，例如
MIN_ELEMENTS <= i and i <= MAX_ELEMENTS -
与0比较的指导原则：
-
隐式地比较逻辑变量
-
把数和0相比较，使用
while (balance != 0) ...而不要使用while (balance) ... -
在C语言中显式地比较字符和
\0 -
把指针与NULL相比较，使用
while (p != NULL) ...而不要用while (p)
-
控制结构域复杂度密切相关。人类大脑很难处理好超过5到9个的智力实体。
第5部分 代码改善（Code Improvement）
第20章 软件质量概述（The Software-Quality Lanscape）
质量不应该被认为是次要目标。组织本身必须向程序员们说明，质量应当放在第一位。
实现软件质量目标的拦路虎之一就是失控的变更。
阅读代码是最有效率的找出缺陷的方法。
没有任何一种错误检测方法能够解决全部问题，测试本身并不是排除错误的最有效方法。成功的质量保证计划应该使用多种不同的技术来检查各种不同类型的错误。
缺陷可能在任何阶段渗透到软件中。因此，你需要在早期阶段就开始强调质量保证工作，并且将其贯彻到项目的余下部分中。质量保证工作应该作为技术脉络的一部分，以及项目的结束点。
提高生产效率和改善质量的最佳途径就是减少花在这种代码返工上的时间，无论返工的代码是由需求，设计改变还是调试引起的。
更多的质量保证工作能降低错误率，但不会增加开发的总成本。编写无缺陷软件并不一定会比编写富含缺陷的软件花更多的时间。开发高质量代码最终并没有要求你付出更多，只是你需要对资源进行重新分配，以低廉的成本来防止缺陷的出现，从而避免代驾高昂的修正工作。
第21章 协同构建（Collaborative Construction）
协同开发实践往往能比测试发现更多的缺陷，并且更有效。
协同开发实践所发现的错误的类型通常跟测试所发现的不同，这意味着你需要同时使用详查和测试来保证你软件的质量。
对代码进行详细检查是减少缺陷的高效方法。
代码详查的记过不应当作为员工表现的评估，因为详查中的代码任然属于开发阶段，评估的依据应该是最终产品而非尚未完成的工作。
进行详查的目的是发现设计或代码总的缺陷，而不是探索替代方案，或者争论谁对谁错，其目的绝不应该是批评作者的设计或者代码。对所有人来说，这一过程都应该是正面的：程序得到了明显改善，参与者都学到了一些东西。
对代码的非正式检查（走查）效果并不好。
软件质量的普遍原理：在减少软件中的缺陷数量的同时，开发周期也能得到缩短。
结对编程的关键（Keys to Success with Pair Programming）
-
统一编码规范
-
不要让结对编程变成旁观
-
不要强迫在简单的问题上使用结对编程
-
有规律地对结对人员和分配的工作任务进行轮换
-
鼓励双方跟上对方的步伐
-
避免新手组合
-
指定一个组长
第22章 开发者测试（Developer Testing）
-
错误并非平均地分布在所有的子程序里面，二是集中在少数几个子程序里面。
-
大多数错误的影响范围是相当有限的（不超过一个子程序）。
-
大多数的构建期的错误是编人员的失误造成的。
-
笔误（拼写错误）是一个常见的问题根源
-
很多错误是由于没有彻底地理解设计
软件质量的普遍原则：开发高质量的软件，比开发低质量软件然后修正的成本要低廉。
第24章 重构（Refactoring）
重构策略：
-
在增加子程序、类时进行重构
-
在修补缺陷时进行重构
-
关注容易出错的模块
-
关注高度复杂的模块
-
如果在维护一个系统，改善你手中正在处理的代码。确保代码在离开你的时候比来之前更健康。
-
定义清楚干净代码和拙劣代码之间的边界，然后尝试把代码移过这条边界。