编程的原则
阅读了《数据结构与程序设计---c++语言描述》这本教材的第一章,觉得受益匪浅,虽然里面有好多不认识的单词,而且好多专业名称还不是很熟悉,查找了一下翻译,基本知道了文章的意思,以下是我的总结,望批评和改正。
一.编写的每个程序、函数和方法要包含准确的前置条件和后置条件。
程序说明的第三部分是它所使用的类和函数的列表,每个程序、函数或方法都应包含一个类似的列表。
二.最审慎地选择类、变量和函数的名称,并予以详尽的解释。
C++在这条技术规则的实施方面有相当的发展,它要求变量声明,而且给予我们几乎无限制的自由来标识名称。在不同的地方使用的常量应赋予名称,不同的数据类型也应如此,所以编译器能够捕获那些本来难以发现的错误。
我们会发现类型和类C++程序中起着根本的作用,并且特别重要的是,他们应该被突出呈现给程序的阅读者。因此我们采用一种大写约定,这一点在life程序中应用:我们对任何类型或程序设计员定义的类型标示符的起始字母使用大写。相反,对函数、变量或常量的标识符则使用小写字母。
名称的审慎选择在阐明程序和避免打印与常见错误方面大有帮助,指导原则如下:
1.特别审慎地选择在程序的不同部分中使用的类、函数、常量和所有全局变量的名称。这些名称应该是有意义的,并且应该能够明确地指示这个类、函数、变量等的目的。
2.对仅是暂时、局部使用的变量,保持其名称简单。数学家通常使用单个字母代表一个变量,因此有时候当我们编写数学程序时,有可能对数学变量使用单个字母的名称。然而,即使是对控制for循环的变量,也经常有可能找到一个个比较短但却有意义的单词,他能更好的描述此变量的用途。
3.使用通用的前缀或后缀来关联同一常规类别的名称。
4.避免采用故意的误拼和无意义的后缀来获得不同的名称。
5.避免选择那些本身意义与问题毫无关系或只有很少关系的漂亮的名称。
6.避免选择拼写互相接近或者其他方面易于混淆的名称。
7.应小心使用字母“l”、“o”和0。在词或数中,通常可以根据上下文区分出它们而不会带来问题,但“l”和“O”绝不应被单独用作名称。
三.保持文档简练但具有描述作用。
文档的风格同所有的书写风格一样,是高度个人化的,许多不同的风格都证明是有效的。尽管如此,还是遵守一些普通接受的指导原则:
1. 在每个函数的开始处放上序言,包括:
(1) 身份证明(程序设计院的名称、日期和版本号)。
(2) 所有函数和算法的目的的说明。
(3) 函数所做的修改及其所使用的数据。
(4) 对程序外部更多文档的引用。
2. 当定义每个变量、常量或类时,解释清楚它是什么及如何使用。如果从名称上就能明显看出这些信息则更好。
3. 对程序的每个重要的片段(段落或函数),用一句注释简要说明他的目的和动作。
4. 如果每个重要片段的结束不明显,则加以指示。
5. 避免机械模仿代码功能的
6. 对任何使用了技巧或意义不清楚的语句加以解释,如果能避免使用这样的语句则更好。
7. 代码本身应解释程序是如何工作的。文档应解释它为什么工作及它做什么。
8. 无论何时修改一个程序,确信文档得到了相应的修改。
四.阅读程序的时间比编写程序的时间多得多。使阅读更容易。
1. 程序中的空格、空白行和缩排是一种重要的文档形式。它们使程序易于阅读,使我们能一眼看出程序的哪些部分彼此相关、哪里出现了主要中断以及每个循环中或者条件语句的每个选择分支当中分别包含哪些语句。有许多系统(有些是自动的)可用于缩排和调整空格,它们的目的都是为了更容易地确定程序的结构。
2. Prettyprinter是一个系统实用程序,它读入一个C++程序,在行间移动文本并调整空行,以此改进程序的外观并使其结构更清晰。如果在你的系统中有Prettyprinter的话,你可以用它做实验,看看它是否有助于改进程序的外观。
3. 由于程序的良好格式的重要性,需要为空格和缩排设置一些合理的规则并在所书写的所有程序中一致地使用这些规则。如果要使格式化系统在阅读程序中有用,则一致性是必要的。
五.不要只见树木不见森林。
这条原理称为自顶向下的细化,是编写能运行的大型程序的真正关键。这一原理隐含着着详细的考虑可以延迟,但精确性和严格并不能延迟。
六.使用类来模拟程序的基本概念。
七.每个函数应该仅仅完成一项任务,但要很好地完成。
也就是说,我们应该能够简洁的描述一个函数的目的。
八.每个类或函数应该隐藏某些东西。
九.保持连接简单。尽可能避免使用全局变量。
十.只要能够避免,切勿引起副作用。如果必须使用全局变量作为输入,则详细地将它们写入文档。
十一. 将输入和输出作为独立的函数,使得它们易于修改并能定制修改以适应计算系统。
十二. 测试数据的质量比数量更重要。
十三. 程序测试可用于说明bug的存在,而不能说明不存在。
十四. 对一个大型且重要的程序,超过一半的工作是在它已被完全调试、测试并投入使用后,来自于维护阶段。
十五. 确信你完全地理解了问题。如果必须改变其条件,则确切地解释所做的修改。
十六. 最精心地设计用户接口,程序的成功很大程度上是靠它的吸引力和易用性。
十七. 除非必要,不要优化代码。大多数程序将90%的时间花在10%的指令上,找出这10%,集中精力提高它的效率。
十八. 尽你所能保持算法简单。当犹豫不决时,选择简单的方式。
十九. 有时延缓问题会简化解决方案。
二十. 重新开始经常比给一个旧程序打补丁更简单。
二十一. 总是计划建设原型丢弃它,不管是否计划都必须这样做。