程序设计实践笔记.docVIP

目 录 第1章 风格 1 1.1 名字 1 1.2 表达式和语句 1 1.3 一致性和习惯用法 1 1.4 函数宏 1 1.5 神秘的数 1 1.6 注释 1 第2章 算法与数据结构 2 2.1 检索 2 2.2 排序 2 2.3 库 2 2.4 一个Java 快速排序 3 2.5 大O记法 3 2.6 可增长数组 3 2.7 表 4 2.8 树 5 2.9 散列表 5 2.10 小结 5 第3章 设计与实现 5 3.1 马尔可夫链算法 6 3.2 数据结构的选择 6 3.3 在C中构造数据结构 6 3.4 生成输出 6 3.5 Java 6 3.6 C++ 6 3.7 Awk和Perl 6 3.8 性能 6 3.9 经验教训 6 第4章 界面 6 4.1 逗号分隔的值 6 4.2 一个原型库 7 4.3 为别人用的库 7 4.4 C++实现 7 4.5 界面原则 7 4.6 资源管理 7 4.7 终止、重试或失败 7 4.8 用户界面 8 第5章 排错 8 5.1 排错系统 8 5.2 好线索，简单错误 8 5.3 无线索，难办的错误 8 5.4 最后的手段 9 5.5 不可重现的错误 9 5.6 排错工具 9 5.7 其他人的程序错误 9 第6章 测试 9 6.1 在编码过程中测试 10 6.2 系统化测试 10 6.3 测试自动化 11 6.4 测试台 11 6.5 应力测试 11 6.6 测试秘诀 11 6.7 谁来测试 11 6.8 测试马尔可夫程序 11 6.9 小结 12 第7章 性能 12 7.1 瓶颈 12 7.2 计时和轮廓 12 7.3 加速策略 13 7.4 代码调整 13 7.5 空间效率 14 7.6 估计 14 第8章 可移植性 14 8.1 语言 14 8.2 头文件和库 14 8.3 程序组织 14 8.4 隔离 14 8.5 数据交换 15 8.6 字节序 15 8.7 可移植性和升级 15 8.8 国际化 15 8.9 小结 15 第9章 记法 15 9.1 数据格式 15 9.2 正则表达式 15 9.3 可编程工具 15 9.4 解释器、编译器和虚拟机 15 9.5 写程序的程序 15 9.6 用宏生成代码 16 9.7 运行中编译 16 附录：规则汇编 16 风格 16 界面 16 排错 17 测试 17 性能 17 可移植性 18  第1章 风格 1.1 名字 全局变量使用具有说明性的名字，局部变量用短名字 函数采用动作性的名字 1.2 表达式和语句 使用表达式的自然形式（应该写得能够大声念出来） 用加括号的方式排除二义性 用缩行显示程序的结构 分解复杂的表达式 要清晰 当心副作用。像++ 这一类运算符具有副作用，它们除了返回一个值外，还将隐含地改变变量的值 1.3 一致性和习惯用法 使用一致的缩排和加括号风格 为了一致性，使用习惯用法 用else-if表达多路选择 1.4 函数宏 避免函数宏，某些时候会使命令执行多次，产生预料之外的结果 1.5 神秘的数 给神秘的数起个名字。作为一个指导原则，除了0和1之外，程序里出现的任何数大概都可以算是神秘的数，它们应该有自己的名字。在程序源代码里，一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息，它们也导致程序难以理解和修改。 把数定义为常数，不要定义为宏。const int SUCCESS = 1 NOT #define SUCCESS 1，C中使用enum来定义。 使用字符形式的常量，不要用整数。 利用语言去计算对象的大小。不要对任何数据类型使用显式写出来的大小。 1.6 注释 不要大谈明显的东西。注释不要去说明明白白的事，比如i++能够将i值加1等等。 给函数和全局数据加注释。注释当然可以有价值。对于函数、全局变量、常数定义、结构和类的域等，以及任何其他加上简短说明就能够帮助理解的内容，我们都应该为之提供注释。 不要注释差的代码，重写它。应该注释所有不寻常的或者可能迷惑人的内容。但是如果注释的长度超过了代码本身，可能就说明这个代码应该修改了。 不要与代码矛盾。许多注释在写的时候与代码是一致的。但是后来由于修正错误，程序改变了，可是注释常常还保持着原来的样子，从而导致注释与代码的脱节。 澄清情况，不要添乱。注释应该在困难的地方尽量帮助读者，而不是给他们设置障碍。 第2章 算法与数据结构 2.1 检索 超过某个界限后(这个界限因实现不同可能有差别)二分检索一定会比线性检索更快 2.2 排序 某一种快速排序： /* quicksort: sort v[0]..v[n-1] into increasing order */ void quicksort(int v[], int n) { int i, last; if (