章节
- 程序设计语言
- 结构化程序设计
- 程序设计风格
- 程序复杂性度量
要点
- 了解什么是结构化程序设计?
- 什么是结构化程序设计的原则?
- 了解程序设计风格的要求?
- 了解程序设计语言的分类和特点?
- 掌握度量程序复杂性的方法?
程序设计语言
一、程序设计语言的分类
- 可分为汇编语言和高级语言二大类
- 从语言的内在特征看,高级语言可分为:系统实现语言,静态高级语言,块结构高级语言和动态高级语言四大类
二、语言的选择
- 应用领域的不同决定选择的语言
- 系统用户的要求决定
- 可以使用的编译程序—运行目标系统的环境中可以提供的编译程序往往限制了对语言的选择
- 程序员的经验和知识
- 软件可移植性要求
- 当工程规模很大时,而又没有完全合适的语言,可编一个专门的语言
- 算法与计算复杂性,软件的可靠性
- 数据结构的复杂性,软件的可维护性
- 效率的考虑
- 了解语言的发展前景
三、语言选择的原则:
- 最少的工作量原则
- 最少的技巧性原则
- 最少错误原则
- 最少维护原则
- 减少记忆原则
程序编码原则:
一、总原则
- 先求正确后求快
- 先求清晰后求快
- 求快不忘保持程序正确
- 保持程序整洁以求快
- 不要因效率而牺牲清晰
二、好程序标准
- 易于测试和调整
- 易于维护
- 易于修改
- 设计简单
- 高效率
结构化程序设计
- 在编程程序时,强调使用几种基本控制结构
- 在程序设计过程中,尽量采用自顶向下和逐步细化的原则,由粗到细,一步步展开
原则:
- 使用语言中的顺序,选择,重复等有限的基本控制结构表示程序逻辑
- 选用的控制结构只准许有一个入口和一个出口
- 复杂结构应该用基本控制结构进行组合嵌套来实现
程序设计风格
程序实际上也是一种供人阅读的文章,有一个文章的风格问题,应该使程序具有良好的风格
-
源程序文档化
-
数据说明
-
语句结构
-
输入/输出方法
源程序文档化
- 标识符的命名
- 安排注释
- 程序的视觉组织
数据说明
- 数据说明的次序应当规范化
- 说明语句中变量安排有序化
- 使用注释说明复杂数据结构
语句结构
- 在一行内只写一条语句
- 程序编写首先应当考虑清晰性
- 程序要能直截了当地说明程序员地用意
- 除非对效率有特殊地要求,程序编写要做到清晰第一,效率第二
- 首先要保证程序正确,然后才要求提高速度
- 避免使用临时变量而使可读性下降。
- 让编译程序做简单的优化
- 尽可能使用库函数
- 避免不必要的转移(goto语句)
- 尽量只采用三种基本的控制结构来编写程序
- 避免使用空的ELSE语句和IF…THEN IF…的语句。这种结构容易使读者产生误解
- 避免采用过于复杂的条件测试
- 尽量减少使用“否定”条件的条件语句
- 尽可能用通俗易懂的伪码来描述程序的流程,然后在翻译成必须使用的语言。
- 数据结构要有利于程序的简化
- 要模块化
- 利于信息隐蔽,确保每一个模块的独立性
- 从数据出发去构造程序
- 不要修补不好的程序,要重新编写
- 对太大的程序,要分块编写,测试,然后在集成
代码设计质量评价
一、正确性
- 程序中没有语法错误
- 程序运行时没有发现明确的运行错误
- 程序中没有不适当的语句
- 用有效的测试数据,得到程序的正确结果
- 用无效的测试数据,得到程序的正确结果–如出错,应给出相应的提示
- 用任何可能的数据,使程序在运行时得到正确的结果
二、结构清晰性
- 是否用种种结构化格式表示程序的控制逻辑
- 是否有一个入口,一个出口
- 是否严格控制GOTO语句
三、易修改性
四、易读性
五、简单性
程序复杂性度量
程序复杂性主要指模块内程序的复杂性
方法:
-
代码行度量法—是统计一个程序模块的源代码行数目,并以源代码行数作为程序复杂性的度量
-
McCabe度量法—又称环路复杂性度量,是一种基于程序控制流的复杂性度量方法
-
Halstead的软件科学—研究确定计算机软件开发中的一些定量规律,它采用一下一组基本的度量值
- 程序长度
- 程序的词汇表
- 程序量
- 程序量比率
- 程序员工作量
- 程序的潜在错误
作业:
- 软件复杂性有哪几类?
① 理解程序的难度;
② 改错及维护程序的难度;
③ 向他人解释程序的难度;
④ 按指定方法修改程序的难度;
⑤ 根据设计文档编写程序的工作量;
⑥ 执行程序时需要资源的程度。
2.软件复杂性度量模型应遵循的基本原则
⑴ 软件复杂性与程序大小的关系不是线性的;
⑵ 控制结构复杂的程序较复杂;
⑶ 数据结构复杂的程序较复杂;
⑷ 转向语句使用不当的程序较复杂;
⑸ 循环结构比选择结构复杂,选择结构又比顺序结构复杂;
⑹ 语句、数据、子程序和模块在程序中的次序对软件复杂性都有影响;
⑺ 全程变量、非局部变量较多时程序较复杂;
⑻ 参数按地址传递比按值传递更复杂;
⑼ 函数副作用比显式参数传递更难以琢磨;
⑽ 具有不同作用的变量共用一个名字时较难理解; ⑾ 模块间或过程间联系密切的程序较复杂; ⑿ 嵌套深度越深程序越复杂。