软工第三次博客
根据现代软件产业的要求，一个软件由一个人单枪匹马完成是不可能的呢？那么就要求我们在相互合作中完成，合作的最小单位是俩个人，两个工程师在一起最多的就是看代码，每个人都会看别人的代码，并发表意见，但是每个人对于好代码的评判是不一致的，这时我们很有必要给出一个基准线——什么是好的代码规范与设计规范。
编码原则：
应尽量避免在系统初始化时运行过多的代码。（此处加入详细原则）
（1）选用控制结构只准许一个入口和一个出口。
（2）程序语句组成容易识别的块，每块只有一个入口和一个出口。 （3）复杂的结构应该用基本控制结构进行组合嵌套来实现。
（4）语句中没有的控制结构，可用一段等价的程序段模拟，但要求该程序段在整个系
统应前后一致。
（5）严格控制GOTO语句，仅在下列情形才可使用。
用一个非结构化的程序设计语言去实现一个结构化的构造。 在某种可以改善而不是损害程序可读性的情况下。
对象命名约定
公式：对象名称=对象前缀+自定义名称（自定义名称要有一定的意义且第一个字母大写）
说明：如果是不需要对其编码的对象，那么对象名用默认对象名。 应该用一致的前缀来命名对象，使人们容易识别对象的类型。下面列出了 Delphi 支持的一些推荐使用的对象约定。
（1）推荐使用的项目前缀
（2）推荐使用的菜单前缀 应用程序频繁使用许多菜单控件，对于这些控件具备一组唯一的命名约定很实用。除了最前面 "mnu" 标记以外，菜单控件的前缀应该被扩展：对每一级嵌套增加一个附加前缀，将最终的菜单的标题放在名称字符串的最后。下表列出了一些例子。
菜单标题序列 菜单处理器名称。
当使用这种命名约定时，一个特定的菜单组的所有成员一个接一个地列在 Visual Basic 的“属性”窗口中。而且，菜单控件的名字清楚地表示出它们所属的菜单项。
（3）为其它控件选择前缀 对于上面没有列出的控件，应该用唯一的由两个或三个字符组成的前缀使它们标准化，以保持一致性。只有当需要澄清时，才使用多于三个字符的前缀。
常量和变量命名约定
公式：常量或变量名称=常量或变量范围前缀+常量或变量类型前缀+自定义名称（自定义名称要有一定的意义且第一个字母大写）
除了对象之外，常量和变量也需要良好格式的命名约定。本节列出了（此处加入变量列表）。
变量应该总是被定义在尽可能小的范围内。全局 (Public) 变量可以导致极其复杂的状态机构，并且使一个应用程序的逻辑非常难于理解。全局变量也使代码的重用和维护更加困难。
Delphi中的变量可以有下列范围： 范围 声明位置 可见位置 过程级（此处加入名称） 模块级（此处加入名称） 全局（此处加入名称）。
较好的编码习惯是尽可能写模块化的代码。例如，如果应用程序显示一个对话框，就把要完成这一对话任务所需要的所有控件和代码放在单一的窗体中。这有助于将应用程序的代码组织在有用的组件中，并减小它运行时的开销。
除了全局变量（应该是不被传递的），过程和函数应该仅对传递给它们的对象操作。在过程中使用的全局变量应该在过程起始处的声明部分中标识出来。 变量范围前缀
随着工程大小的增长，划分变量范围的工作也迅速增加。在类型前缀的前面放置单字母范围前缀标明了这种增长，但变量名的长度并没有增加很多。 范围 前缀 例子 全局 g GstrUserName 模块级 m MblnCalcInProgress 本地到过程 无 DblVelocity
（此处加入说明） 变量
声明所有的变量将会（此处加入说明）。
应该给变量加前缀来指明它们的数据类型。而且前缀可以被扩展，用来指明变量范围，特别是对大型程序。
变量数据类型
用下列前缀来指明一个变量的数据类型。 （此处加入说明） 描述变量和过程名
变量或过程名的主体应该使用大小写混合形式，并且应该足够长以描述它的作用。而且，函数名。
对于频繁使用的或长的项，推荐使用标准缩略语以使名称的长度合理化。一般来说，（此处加入特例说明）就困难了。
当使用缩略语时，要确保它们在整个应用程序中的一致性。在一个工程中，如果一会儿使用（此处加入说明问题），将导致不必要的混淆。
签入
所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
(1)对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。
(2)修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。
(3)从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。
我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。
浙公网安备 33010602011771号