|
|
知识路径： > 信息系统工程技术知识 > 软件与软件工程知识 > 软件开发工具基础知识 > 程序编写 >
|
|
相关知识点：3个
|
|
|
|
|
程序设计风格包括4个方面：源程序文档化、数据说明、语句结构和输入输出方法，力图从编码原则的角度提高程序的可读性，改善程序质量。
|
|
|
|
|
|
（1）符号名的命名。符号名即标识符，包括模块名、变量名、常量名、子程序名、数据区名、缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。应当选择精炼的、意义明确的名字，改善对程序功能的理解。必要时可使用缩写名字，但缩写规则要一致，并且要给每一个名字加注释。在一个程序中，一个变量只应用于一种用途。就是说，在同一个程序中一个变量不能身兼几种工作。
|
|
|
|
（2）程序的注释。正确的注释能够帮助读者理解程序，可为后续阶段进行测试和维护提供明确的指导。一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。注释可分为序言性注释和功能性注释。
|
|
|
|
序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有关项目包括程序标题、有关本模块功能和目的的说明、主要算法、接口说明、有关数据描述、模块位置、开发简历等。
|
|
|
|
功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，不要解释下面怎么做，因为解释怎么做常常是与程序本身重复的，并且对于阅读者理解程序没有什么帮助。书写功能性注释要注意：
|
|
|
|
|
|
|
|
|
|
（3）视觉组织。利用空格、空行和移行提高程序的可视化程度。恰当地利用空格，可以突出运算的优先性，避免发生运算的错误。自然的程序段之间可用空行隔开；对于选择语句和循环语句，把其中的程序段语句向右做阶梯式移行。这样可使程序的逻辑结构更加清晰，层次更加分明。
|
|
|
|
|
|
在编写程序时，需注意数据说明的风格。为了使程序中的数据说明更易于理解和维护，必须注意以下几点。
|
|
|
|
（1）数据说明的次序应当规范化，使数据属性容易查找。
|
|
|
|
（2）当多个变量名用一个语句说明时，应当对这些变量按字母的顺序排列。
|
|
|
|
（3）如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。
|
|
|
|
|
|
在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单，直接，不能为了片面追求效率而使语句复杂化。
|
|
|
|
（1）在一行内只写一条语句，并且采取适当的移行格式，使程序的逻辑和功能变得更加明确。
|
|
|
|
（2）程序编写首先应当考虑清晰性，不要刻意追求技巧性，使程序编写得过于紧凑。
|
|
|
|
（3）程序编写得要简单，写清楚，直截了当地说明程序员的用意。
|
|
|
|
（4）除非对效率有特殊的要求，否则程序编写要做到清晰第一，效率第二。不要为了追求效率而丧失了清晰性。事实上，程序效率的提高主要应通过选择高效的算法来实现。
|
|
|
|
（5）首先要保证程序正确，然后才要求提高速度。反过来说，在使程序高速运行时，首先要保证它是正确的。
|
|
|
|
|
|
|
|
|
|
（9）尽量用公共过程或子程序去代替重复的功能代码段。
|
|
|
|
|
|
（11）使用括号来清晰地表达算术表达式和逻辑表达式的运算顺序。
|
|
|
|
（12）避免不必要的转移。同时如果能保持程序的可读性，则不必用GOTO语句。
|
|
|
|
|
|
|
|
（15）避免使用空的ELSE语句和IF…THEN IF…的语句。
|
|
|
|
（16）避免使用ELSE GOTO和ELSE RETURN结构。
|
|
|
|
|
|
|
|
（19）尽量减少使用“否定”条件的条件语句，不要让读者绕弯子想。
|
|
|
|
|
|
|
|
|
|
|
|
（24）尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言。
|
|
|
|
|
|
（26）要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见。
|
|
|
|
|
|
|
|
（29）不要修补不好的程序，要重新编写。也不要一味地追求代码的复用，要重新组织。
|
|
|
|
（30）对太大的程序，要分块编写、测试，然后再集成。
|
|
|
|
|
|
（32）注意计算机浮点数运算的特点，例如浮点数运算10.0×0.1通常不等于1.0。
|
|
|
|
（33）不要单独进行浮点数的比较。用它们做比较，其结果常常发生异常情况。
|
|
|
|
（34）避免不恰当地追求程序效率，在改进效率前，要做出有关效率的定量估计。
|
|
|
|
（35）在程序中应有出错处理功能，一旦出现故障时不要让机器进行干预，导致停工。
|
|
|
|
|
|
输入和输出信息是与用户的使用直接相关的。输入和输出的方式及格式应当尽可能方便用户的使用。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。
|
|
|
|
不论是批处理的输入输出方式，还是交互式的输入输出方式，在设计和程序编码时都应考虑下列原则：
|
|
|
|
（1）对所有的输入数据都进行检验，从而识别错误的输入，以保证每个数据的有效性。
|
|
|
|
（2）检查输入项的各种重要组合的合理性，必要时报告输入状态信息。
|
|
|
|
（3）使得输入的步骤和操作尽可能简单，并保持简单的输入格式。
|
|
|
|
|
|
|
|
（6）输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。
|
|
|
|
（7）在以交互式输入输出方式进行输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息。
|
|
|
|
（8）当程序设计语言对输入输出格式有严格要求时，应保持输入格式与输入语句的要求的一致性。
|
|
|
|
|
|
输入输出风格还受到许多其他因素的影响。如输入输出设备（例如终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。
|
|
|
|
Wasserman为“用户软件工程及交互系统的设计”提供了一组指导性原则，可供软件设计和编程参考。
|
|
|
|
（1）把计算机系统的内部特性隐蔽起来不让用户看到。
|
|
|
|
（2）有完备的输入出错检查和出错恢复措施，在程序执行过程中尽量排除由于用户的原因而造成程序出错的可能性。
|
|
|
|
|
|
（4）充分利用联机帮助手段，对于不熟练的用户，提供对话式服务；对于熟练的用户，提供较高级的系统服务，改善输入输出的能力。
|
|
|
|
（5）使输入格式和操作要求与用户的技术水平相适应。对于不熟练的用户，充分利用菜单系统逐步引导用户操作；对于熟练的用户，允许绕过菜单，直接使用命令方式进行操作。
|
|
|
|
|
|
|
|
|
|
|
|
在交互式系统中，这些要求应成为软件需求的一部分，并通过设计和编码，在用户和系统之间建立良好的通信接口。
|
|
|
