5、程序编码规范
变量命名约定
前台VB程序变量约定，变量名由前缀和中文名称组成，即：AB变量名，其中A 表示该变量的范围即：
后台Oracle存储过程，函数以及触发器也可能使用到变量，与VB程序约定一致，如：
?VB过程命名约定
由于VB的过程不返回任何值，因此在过程名前加动词Do，代表要做一件事，如：Private Sub Do设置窗口颜色(vl颜色值 As Long)
……
End Sub
?VB函数命名约定
由于VB的函数除了要处理一件事或做一个计算外，还要返回一个值，因此在函数名前加动词Get ，代表要得到一个值，如：
Private Sub Get得到拼音简码(vs中文字串 As String)
……
End Sub
?Oracle 存储过程约定
Oracle 存储过程通常要处理一件事，并且要通过一个参数返回一个结果，每个存储过程名前加入Do，如：
CREATE OR REPLACE PROCEDURE Do出库单审核
( vs操作类型 In nvarchar2,
vl单据序号 In numeric,
vl同步序号 In numeric,
vl操作员 In numeric,
ps处理成功 Out nvarchar2,
ps失败描述 Out nvarchar2
)
IS
Begin
……
ps处理成功:='是';
End Do出库单审核;
C语言编程规范 对于程序员来说，能工作的代码并不等于“好”的代码。“好”代码的指标很多，包括易读、易维护、易移植和可靠等。其中，可靠性对嵌入式系统非常重要，尤其是在那些对安全性要求很高的系统中，如飞行器、汽车和工业控制中。这些系统的特点是：只要工作稍有偏差，就有可能造成重大损失或者人员伤亡。一个不容易出错的系统，除了要有很好的硬件设计(如电磁兼容性)，还要有很健壮或者说“安全”的程序。 然而，很少有程序员知道什么样的程序是安全的程序。很多程序只是表面上可以干活，还存在着大量的隐患。当然，这其中也有C语言自身的原因。因为C语言是一门难以掌握的语言，其灵活的编程方式和语法规则对于一个新手来说很可能会成为机关重重的陷阱。同时，C语言的定义还并不完全，即使是国际通用的C语言标准，也还存在着很多未完全定义的地方。要求所有的嵌入式程序员都成为C语言专家，避开所有可能带来危险的编程方式，是不现实的。最好的方法是有一个针对安全性的C语言编程规范，告诉程序员该如何做。 本规范在制定过程中，主要参考了业界比较推崇的《华为软件编程规范和范例》和《MI SRA 2004规则》，适合C语言初学者使用，目的在于在教学中培养学生良好的编程规范和意识、素质，促进所设计程序安全、健壮、可靠、可读与可维护(程序简单、清晰)。考虑到面向的是初学者，为便于教学和课程考核操作，本规范中的要求比较基本。事实上，很多公司都有自己规定的代码风格，包括命名规则、缩进规则等，学生参加工作后，应再进一步学习和应用公司的规范。 建议学生在学习本规范的同时，花点时间阅读本规范的参考文献原文，特别是熟读本规范的参考文献之一的《“安全第一”的C语言编程规范》，深刻理解编程规范与程序安全、健壮、可靠、可读、可维护间的关系和作用，在学习和工作中养成良好的编程风格。 1 排版 1.1 严格采用阶梯层次组织程序代码 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case 语句下的情况处理语句也要遵从语句缩进要求。 程序块的分界符(如C/C++ 语言的大括号‘{’和‘}’)应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if 、for 、do 、while 、switch 、case 语句中的程序都要采用如上的缩进方式。 各层次缩进的风格采用TAB缩进(TAB宽度原则上使用系统默认值，TC使用8空格宽度，VC使用4空格宽度)。示例：
百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}
程序的书写规则(程序的编码规范) 随着软件产品的功能增加和版本的提高，代码越来越复杂，源文件也越来越多，对于软件开发人员来说，除了保证程序运行的正确性和提高代码的运行效率之外，规范风格的编码会对软件的升级、修改、维护带来极大的方便性，也保证程序员不会陷入“代码泥潭”中无法自拔。开发一个成熟的软件产品，除了有详细丰富的开发文档之外，必须在编写代码的时候就有条不紊，细致严谨。 以下的编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等注意事项。 一、排版： 1.关键词和操作符之间加适当的空格。 2.相对独立的程序块与块之间加空行 3.较长的语句、表达式等要分成多行书写。 4.划分出的新行要进行适应的缩进，使排版整齐，语句可读。 5.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。 6.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。 7.若函数或过程中的参数较长，则要进行适当的划分。 8.不允许把多个短语句写在一行中，即一行只写一条语句。 9.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风 格。 10.C/C 语言是用大括号‘{’和‘}’界定一段程序块的，编写程序块时‘{’和 ‘}’应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
二、注释 1.注释要简单明了。 2.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。 3.在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防 止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。 4.对代码的注释应放在其上方相邻位置，不可放在下面。 5.对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域 的注释应放在此域的右方；同一结构中不同域的注释要对齐。 6.变量、常量的注释应放在其上方相邻位置或右方。 7.全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取 它以及存取时注意事项等的说明。 8.在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生 成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。 9.在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能 描述；输入、输出及返回值说明；调用关系及被调用关系说明等。 三、命名 1.较短的单词可通过去掉“元音”形成缩写； 2.较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序， 避免使用默认优先级。 3.使用匈牙利表示法 四、可读性 1.避免使用不易理解的数字，用有意义的标识来替代。 2.不要使用难懂的技巧性很高的语句。
FORTRAN 90 程序编程规范 Fortran 90 编程规范，使程序代码高度组织化，更加易读、易懂、易于维护，程序更加高效。使编出的程序更易懂、易于维护。 1 语言选择 数值预报创新系统软件开发应避免使用Fortran77 的某些过时特征以Fortran 90不一致的特征。选择Fortran 90 作为开发语言，并采用Fortran 90 的新功能，如动态内存的分配(dynamic memory allocation)、递归（recursion ）, 模块(modules)、POINTER 、长变量名、自由格式等。 Fortran 77其中某些只是一些冗余的功能，这些功能已经过时，另外，还有一些在Fortran90 中被证明是不好的用法，建议不要使用。 2 Fortran 90 的新特性 2.1.1 建议使用的Fortran 90 新特性 建议使用Fortran 90 提供的模块（module ），并用Use ONLY 指定module 中哪些变量或派生类型定义可用于调用程序。 尽量使用数组下标三元组，这样可优化并减少所需的代码行数。为提高可读性，要在括号内表明数组的维数，例如： 1dArrayA(:) = 1dArrayB(:) + 1dArrayC(:) 2dArray(: , :) = scalar * Another2dArray(: , :) 当访问数组的子集时，例如在有限差分等式中，可以通过使用下标三元组实现。例如：2dArray(: , 2:len2) = scalar *（ & Another2dArray(:, 1:len2 -1) & - Another2dArray(:, 2:len2) & ) 对程序单元（program units ）命名，并使用End program ，End subroutine ，End interface ，End module 等结构再次指定“program unit ”的名称。 在逻辑表达式中使用>、 >=、 ==、 <、 <=、 /=，它们分别代 替.gt.、.ge.、.eq.、.lt.、.le.、.ne. 。新的表示方法更接近标准的数学符号 在变量定义中始终使用“：：”；始终用“DIMENSION ”定义数组形状；始终用（len=）的语法格式声明字符变量的长度。
蜗牛游戏程序编码规范 (版本 0.1) 规范说明:............................................................. 一、命名规则...................................................... 二、程序的版式.................................................... 三、注释.......................................................... 四、服务端平台无关................................................ 五、服务端表格操作................................................ 六、客户端文件读写................................................ 七、客户端内存操作................................................ 八、脚本内的注释.................................................. 规范说明: 制定该规范的目的是让程序清晰易懂、易维护、易管理。该规范为强制规范，必须执行，如果有没涉及的地方请参考《高质量C++-C编程指南》。当所在编程环境(如MFC、Linux)与本规范有差异时，可以使用所在编程环境的规范，但是同一个项目必须是统一的规范。 最后希望大家都能养成一个良好的程序习惯，一个好的习惯受益终身！ 一、命名规则 1．所有命名应当直观且可拼读，并具有实际意义； 2．类名和函数名用大写字母开头的单词组合而成,接口类名以I开头； 3．常量全用大写的字母，用下划线分割单词，尽量不要使用宏； 4．类的数据成员加前缀m_，全局变量加前缀g_，静态变量加前缀s_； 5．变量名第一个字母小写，使用“名词”或“形容词+名词”的词义表示法； 示例: ·局部变量 char *pStringBuffer； int &stringFindResult； bool isEngineStartup； ·函数命名 unsigned int GetVoyageCoreState(); static bool GetVoyageServiceCount(int &count); ·结构类型
后台Java程序编码标准
————————————————————————————————作者：————————————————————————————————日期：
Java程序编码规范 后台技术中心 编写人：汪源 编写时间：2009-3-27 部门名：后台技术中心
修订记录 编号修订内容简述修订日期版本修订人1 初始版本2009-3-27 0.1 汪源
总体约定 1.一个工程中的所有文件应统一使用GBK或UTF-8编码。 2.代码使用大小为4的TAB缩进。 3.代码使用package组织，package名应以https://www.doczj.com/doc/0813090722.html,ease.开关。 4.使用Vector等集合框架类时，应指定模板类型参数。 命名规范 类名、文件名、枚举变量等统一使用首字母大写，如 01 class TableInfo { 02 ... 03 }; 函数参数、局部变量、函数名等统一使用Sun风格的命名，即第一个单词小写，其它单词首字母大写，如： 01 int maxLength; 02 NtseIndex *primaryKey; 03 bool dropTable(...) { 04 // 05 } 不允许使用匈牙利式命名法。 常量统一使用全大写，单词之间用_连接，如: 01 static final int NTSE_NAME_LEN; 目录名统一使用全小写字母，单词之间用-连接。 语句 主要是{放在同一行及空格使用上的约定。 if/else形如（注意其中每个空格的位置）: 01 if (xxx) { 02 ... 03 } else if (xxx) { 04 ... 05 } else { 06 ... 07 }
软件编码规范 中国人民银行清算总中心 支付系统开发中心
注：变化状态：A—增加，M—修改，D—删除
目录 第一篇C/C++编码规范 (6) 第一章代码组织 (6) 第二章命名 (9) 2.1文件命名 (9) 2.2变量命名 (9) 2.3常量与宏命名 (10) 2.4类命名 (10) 2.5函数命名 (10) 2.6参数命名 (11) 第三章注释 (12) 3.1文档化注释 (12) 3.2语句块注释 (17) 3.3代码维护注释 (20) 第四章编码风格 (22) 4.1排版风格 (22) 4.2头文件 (26) 4.3宏定义 (27) 4.4变量与常量 (30) 4.5条件判断 (32) 4.6空间申请与释放 (33) 4.7函数编写 (33) 4.8类的编写 (37) 4.9异常处理 (40) 4.10特殊限制 (40) 第五章编译 (41) 第六章ESQL/C编码 (46) 第二篇JAVA编码规范 (47) 第一章代码组织 (48) 第二章命名 (51) 2.1包命名 (51) 2.2类命名 (51) 2.3接口命名 (51) 2.4方法命名 (51) 2.5变量命名 (51) 2.6类变量命名 (52) 2.7常量命名 (52) 2.8参数命名 (52) 第三章注释 (53) 3.1文档化注释 (53) 3.2语句块注释 (57) 3.3代码维护注释 (59) 第四章编码风格 (61) 4.1排版风格 (61) 4.2包与类引用 (66) 4.3变量与常量 (66) 4.4类编写 (67) 4.5方法编写 (68)
4.6异常处理 (71) 4.7特殊限制 (71) 第五章编译 (73) 第六章JSP编码 (74) 6.1文件命名及存放位置 (74) 6.2内容组织 (74) 6.3编码风格 (76) 6.4注释 (78) 6.5缩进与对齐 (78) 6.6表达式 (79) 6.7JavaScript (79) 第三篇POWERBUILDER编码规范 (80) 第一章代码组织 (81) 第二章命名 (82) 2.1文件命名 (82) 2.2对象命名 (82) 2.3变量命名 (84) 2.4常量命名 (85) 2.5函数与事件命名 (85) 2.6参数命名 (85) 第三章注释 (85) 3.1文档化注释 (85) 3.2语句块注释 (88) 3.3代码维护注释 (88) 第四章编码风格 (89) 4.1界面风格 (89) 4.2排版风格 (93) 4.3变量与常量 (95) 4.4条件判断 (96) 4.5空间申请与释放 (97) 4.6函数编写 (97) 4.7特殊限制 (97) 第五章SQL编码 (98)
"\n"。 HTML Tab。 作
遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ?静态字段 ?缩小作用域 ?公共方法和字段 ?保护包 ?尽可能使对象不可变（immutable） ?序列化 ?清除敏感信息 1) 静态字段 避免使用非final的公共静态变量，应尽可能地避免使用非final公共静态变量，因为无法判断代码有无权限改变这些静态变量的值。 一般地，应谨慎使用可变的静态状态，因为这可能导致设想中应该相互独立的子系统之间发生不曾预期的交互。 2) 缩小作用域 作为一个惯例，尽可能缩小成员方法和成员变量的作用域。检查包访问权限成员（package-private）能否改成私有成员（private），保护访问成员（protected）可否改成包访问权限成员（package-private）/私有成员（private）等等。 3) 公共方法/字段 公共变量应当避免使用，访问这些变量时应当通过getter/setter法。在这种方式下，必要时可以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： private static TimeZone defaultZone = null; public static synchronized void setDefault(TimeZone zone) { defaultZone = zone;
8051单片机汇编程序编码规范 引言 软件设计更多地是一种工程，而不是一种个人艺术。如果不统一编程规范，最终写出的程序，其可读性将较差，这不仅给代码的理解带来障碍，增加维护阶段的工作量，同时不规范的代码隐含错误的可能性也比较大。 分析表明，编码阶段产生的错误当中，语法错误大概占20%左右，而由于未严格检查软件逻辑导致的错误、函数（模块）之间接口错误及由于代码可理解度低导致优化维护阶段对代码的错误修改引起的错误则占了一半以上。 可见，提高软件质量必须降低编码阶段的错误率。如何有效降低编码阶段的错误呢？这需要制定详细的软件编程规范，并培训每一位程序员，最终的结果可以把编码阶段的错误降至10%左右，同时也降低了程序的测试费用，效果相当显著。 本文从代码的可维护性（可读性、可理解性、可修改性）、代码逻辑与效率、函数（模块）接口、可测试性四个方面阐述了软件编程规范，规范分成规则和建议两种，其中规则部分为强制执行项目，而建议部分则不作强制，可根据习惯取舍。 1．排版 规则1 程序块使用缩进方式，函数和标号使用空格缩进，程序段混合使用TAB和空格缩进。缩进的目的是使程序结构清晰，便于阅读和理解。
精心整理软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。 2) 3) 4) ● ● ● ● ● 5) 6) 7) 8) 9) 13) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 14) log的生成环境上尽量避免输出文件名和行号。 15) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。作为一种 特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终端用户不能访问的程序代码。但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
2. JAVA安全 遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ? ? ? ? ? ? ? 1) 2) （ 3) 以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： privatestaticTimeZonedefaultZone=null; publicstaticsynchronizedvoidsetDefault(TimeZonezone) { defaultZone=zone;
华为软件编程规范和范例 〔一〕=====[排版] ]=======. 〔二〕======[注释]=======. 〔三〕=====[标识符命名]=======. 〔四〕=====[可读性]======. 〔五〕=====[变量、结构]=====. 〔六〕=====[函数、过程]=====. 〔七〕=====[可测性]=====. 〔八〕=====[程序效率]=====. 〔九〕=====[质量保证]=====. 〔十〕=====[代码编辑、编译、审查]=====. 〔十一〕=====[代码测试、维护]=====. 〔十二〕=====[宏]=====. 〔一〕========[ 排版]========== 11-1：程序块要采用缩进风格编写，缩进的空格数为4个 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行 示例：如下例子不符合规范。 Int ni; if (!valid_ni(ni)) { ... // program code } repssn_ind = ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 Int ni; if (!valid_ni(ni)) { ... // program code } repssn_ind = ssn_data[index].repssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读 示例： perm_count_msg.head.len = NO7_TO_STAT_PERM_COUNT_LEN
目录 1 总体要求 (3) 2 命名规范 (3) 2.1 概述 (3) 2.2 文件命名规范 (3) 2.3 函数命名规范 (3) 2.4 变量命名规范 (3) 2.5 常量命名规范 (4) 2.6 数据库表命名规范 (4) 3 注释规范 (4) 3.1 概述 (4) 3.2 代码文件的注释 (4) 3.3 数据对象的注释 (5) 4 程序书写格式 (5) 4.1 空格、空行与缩进 (5) 4.2 SQL语句书写规范 (5) 4.3 其它规范 (6) 4.4 详细和编辑页的权限判断顺序 (6) 5 编程准则 (6) 5.1 变量使用规范 (6) 5.2 数据库操作规范 (6) 5.3 对象使用规范 (6) 5.4 模块设计原则 (6) 5.5 数据库表设计原则 (7) 6 界面设计规范 (7) 6.1 基本原则 (7) 6.2 版面样式 (7) 6.3 保持页面的一致性 (7) 6.4 文字表述 (7) 6.5 B/S构架适用原则 (8) 7 主要名词/动词汉英对照表 (8)
8 缩写标准 (9) 8.1 常用缩写 (9) 8.2 前缀缩写 (9) 8.2.1 类型前缀 (9) 8.2.2 控件前缀 (10)
程序设计和编码规范 1总体要求 1、必须严格执行本规范以确保源代码的可读性及可维护性。 2、所有的程序文件都必须有注释文字，并严格按照本规范中的“注释规范”书写。 3、必须使用泰捷控件库提供的公用控件和公用函数。 4、同一个项目中必须使用相同的开发语言。 5、保持每个程序文件的程序书写格式一致，功能相似的页面控件引用顺序也应该是 一致的。 2命名规范 2.1概述 1、必须使用美国英语标准英文单词，不允许使用中文拼音（中文地名和人名除外）。 2、选择使用频率较高的常用词。 3、如果有名词，必须使用单数形式。 4、使用大小写混合格式，将连接的几个单词首字母大写。 5、必须在3至30个字母以内,临时的循环变量可以使用一个字母，如i，j，k等。 6、如果使用缩写，必须使用本规范附录的缩写范例。 2.2文件命名规范 1、文件命名采用主谓结构，首字母大写，如CustomerEdit.aspx。 2、文件和文件夹的名称应该精确地说明它们的用途。 2.3函数命名规范 1、函数名和方法名以动词开始，首字母大写，如SaveFileLog。 2、在命名函数时包括返回值的说明，如GetFileName。 3、类名和属性名以名词开始，不加前缀，首字母大写，如EmployeeName。 4、在不同的类中的属性，如果它们有相同的作用，则必须使用同样的名称。 2.4变量命名规范 1、变量可以加前缀，前缀使用2至4个字母，全部小写；public变量不要加前缀。
程序员编码规范 目录 1.导言 1.1目的 1.2范围 1.3缩写说明 1.4术语定义 1.5引用标准 1.6参考资料 1.7版本更新信息 2. 编码格式规范 3.命名规范 3. 1命名的基本约定 3. 2各种标示符类型的命名约定 3. 3组件名称缩写列表 4．声明规范 4.1变量声明 4.2代码缩进 4.3空白 5．语句规范 6.注释规范 6. 1注释的方法 6. 2开头注释 6. 3类和接口的注释
1.导言 1.1目的 该文档的目的是描述网上招聘系统项目的编码规范和对代码的说明，其主要内容包括： ●编码规范 ●命名规范 ●注释规范 ●语句规范 ●声明规范 ●目录设置 ●代码说明 本文档的预期的读者是： ●开发人员 ●项目管理人员 ●质量保证人员 1.2范围 该文档定义了本项目的代码编写规范，以及部分代码描述和所有代码的说明。 1.3缩写说明 Aspx Aspx是Active Server Pages XML的缩写。 1.4术语定义 Class C#程序的单元。 Packages
由很多的类组成的工作包。 1.5引用标准 [1] 《企业文档格式标准》 北京长江软件有限公司 1.6参考资料 书名：《系统分析设计技术》作者：张友生 《C#程序设计》 2. 编码格式规范 1．代码书写格式 （1）所有的缩进TAB键为4个空格，每个单词的首字符大写，其余小写。 （2）在代码中垂直对齐左括号和右括号。 例： if(x==0) { Response.Write("用户名必须输入！"); } 不允许以下情况： if(x==0) { Response.Write("用户名必须输入！"); }或者 if(x==0) { Response.Write("用户名必须输入！"); } （3）在大多数运算符之前和之后使用空格，这样做时不会改变代码的的 意图却可以使代码容易阅读。例：int j = i + k;而不应写为：int j=i+k; （4）缩写SQL语句时，对于关键字使用全部大写，对于数据库元素（如 表，列和视图）使用大小写混合）。 （5）将每个主要的SQL子句放在不同的行上，这样更容易阅读和编辑 语句。
C语言程序代码编写规范 （初级程序员讨论版） 前言 一个好的程序编写规范是编写高质量程序的保证。清晰、规范的源程序不仅仅是方便阅读，更重要的是能够便于检查错误，提高调试效率，从而最终保证软件的质量和可维护性。 说明 此文挡还在完善改进中，如有不足，欢迎指正。 本文档主要适用于刚刚开始接触编程的初学者。 对于具有一定工程项目开发经验的程序员，建议学习C语言程序代码编写规范 —高级版。 目录 1代码书写规范 2注释书写规范 3命名规范
内容 1 代码书写规范 函数定义 每个函数的定义和说明应该从第1列开始书写。函数名（包括参数表）和函数体的花括号（“{”和“}”）应该各占一行。在函数体结尾的括号（“}”）后面应该加上注释，注释中应该包括函数名，这样比较方便进行括号配对检查，也可以清晰地看出来函数是否结束。 范例1：函数的声明 void matMyFunction(int n) { …… } /* matMyFunction*/ 空格的使用 使用空格分割所有演算符号和操作数。 这条规则的例外是“->”,““.”, “()”和“[]”，这些操作符和操作数之间不空格。 当需要把一个程序行的内容分成几行写时，操作符号应该放在行末，而不是下一行的开头。 缩进的设置 代码书写应该遵从结构化的要求，采用缩进的格式。最小缩进量为4个空格，整个文件内部应该统一，不要混用Tab键和4个空格这两种情况，因为不同的编辑器对Tab键的处理方法不同。 折行的使用 每行的长度不要超过80个字符，当程序行太长时，应该分行书写。 分行时应该按照自然的逻辑关系进行，例如：不要把一个简单的逻辑判断写在 两行上。 分行后的缩进应该按照程序的逻辑关系进行对齐。例如：参数表折行后，下面 的行应该在参数表左括号的下方。 范例2：折行的格式
软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。 2) 代码中每个类名上的注释必须留下创建者和修改者的名字。 3) 每个需要import的类都应使用一行import声明，不得使用import xxx.*。 4) System.out.println()仅在调试时使用，正式代码里不应出现。 5) 开发人员编写代码时应遵循以下命名规则： ●Package 名称应该都是由一组小写字母组成； ●Class 名称中的每个单词的首字母必须大写； ●Static Final 变量的名称全用大写，并且名称后加注释； ●参数的名称必须和变量的命名规范一致； ●使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名称。 6) 代码应该用unix的格式，而不是windows的。 7) exit 除了在main 中可以被调用外，其他的地方不应被调用。 8) 代码中应尽量使用interfaces，不要使用abstract类。 9) 在需要换行的情况下，尽量使用println 来代替在字符串中使用的"\n"。 10) 涉及HTML的文档，尽量使用XHTML1.0 transitional文件类型，其中所有HTML 标签都应关闭。 11) 在HTML、JavaScript、XML代码中，缩进应为两个空格，不得使用Tab。 12) HTML标签的name和id属性的命名方式应与Java变量名相同。 13) 在需要经常创建开销较大的对象时，开发人员应考虑使用对象池。 14) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 15) log的生成环境上尽量避免输出文件名和行号。 16) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。作 为一种特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终 端用户不能访问的程序代码。但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
嵌入式程序编码规范 一、基本要求 1.程序总体要求 1.1程序结构清析，简单易懂，单个函数的程序行数不得超过200行。 1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。 1.3尽量使用标准库函数和公共函数。 1.4不要随意定义全局变量，尽量使用局部变量。 1.5使用括号以避免二义性。 1.6单元测试也是编程的一部份，编写程序时，亦必须想好测试的方法。即"单元测试"的 测试方案应在编写程序是一并拟好并提交。 2.可读性要求 2.1可读性第一，效率第二。 2.2保持注释与代码完全一致。 2.3每个源程序文件，都有文件头说明，说明规格见规范。 2.4每个函数，都有函数头说明，说明规格见规范。 2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。 2.7常量定义（DEFINE）有相应说明。 2.8处理过程的每个阶段都有相关注释说明。 2.9在典型算法前都有注释。 2.10利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为6个 字节。 2.11循环、分支层次不要超过五层。 2.12注释可以与语句在同一行，也可以在上行。 2.13空行和空白字符也是一种特殊注释。 2.14一目了然的语句不加注释。 2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。 2.16注释行数（不包括程序头和函数头说明部份）应占总行数的1/5到1/3。 3.结构化要求 3.1禁止出现两条等价的支路。 3.2禁止GOTO语句。 3.3用IF语句来强调只执行两组语句中的一组。禁止ELSE GOTO和ELSE RETURN。 3.4用CASE实现多路分支。 3.5避免从循环引出多个出口。 3.6函数只有一个出口。 3.7不鼓励使用条件赋值语句。 3.8避免不必要的分支。 3.9不要轻易用条件分支去替换逻辑表达式。 4.正确性与容错性要求
软件版本管理规范
Revision List
目录 一、目的.......................................... - 4 - 二、适用范围........................................ - 4 - 三、版本定义规范. ......................................................................... - 4 - 四、版本代码设计规范. ................................................................... - 4 - 五、版本进阶规范. ......................................................................... - 5 - 六、软件备份要求规范. ................................................................... - 5 - 七、软件版本发布规范. ................................................................... - 5 - 八、软件发布流程规范. ................................................................... - 7 - 九、量产中软件管理规范. ................................................................. - 8 -
C++语言程序设计代码规范 1 命名规范 本规范对变量、函数、类（结构）等的名称有严格的规定，在编码过程中务必遵守。 1.1 变量命名规范 变量名称采用匈牙利命名法，即：完整的名称由“缀”和“主体”复合而成。“缀”用于指示变量的种类、数值类型、作用域等属性，由小写字符和下划线（_）组成，根据其附着在“主体”的位置分为前缀和后缀两种。“主体”表示变量的语义。 整个变量名称的格式如下： <作用域前缀>[<指针缀>]<类型缀><主体><作用域后缀> 下面详细论述。 1.1.1 作用域缀（前缀和后缀） 作用域前缀处在整个变量名的最前面。常用的作用域前缀为： 作用域后缀处在整个变量名的最后面。只有一种情况使用作用域后缀，就是函数的形参必须以作用域后缀结束。 1.1.2 指针缀 如果一个变量是指针，则必须使用指针缀。指针缀使用字母p表示。 以前，在DOS平台下有短指针和长指针的区别，有时称长指针为lp。在Win32平台下已经不存在这个区别了，所以统一使用p, 而不是lp。 1.1.3 类型缀 类型缀由小写字符构成，用于描述变量的类型。注意： 1.不要私自创造出各种各样的前缀。 2.也没有必要在前缀中仔细区分一些细小的类型区别，那样会给代码维护工作带来额外的麻烦。 常用的类型前缀为：
对于其他不在上面表中的结构、类等复杂数据类型，特别是不常使用的和不通用的，不使用前缀。例如： class Person Jonson; struct DateTime MyDt; 在应用场合明确的情况下，例如：简单的局部变量，它的值类型前缀有时可以省略。具体见下面的例子。 1.1.4 复合前缀 根据以上规则，变量根据它所在的作用域、类型、是否是指针，得到一个复合前缀。例如： char g_szFileName[_MAX_PATH]; //全局字符串变量 char* g_pszFileName; //全局字符串指针变量： char s_szFileName[_MAX_PATH]; //静态字符串变量 char* s_pszFileName; //静态字符串指针变量： char _s_szFileName[_MAX_PATH]; //局部静态字符串变量 char* _s_pszFileName; //局部静态字符串指针变量： char m_szFileName[_MAX_PATH]; //类字符串变量 char* m_pszFileName; //类字符串指针变量： char ms_szFileName[_MAX_PATH]; //类静态字符串变量 char* ms_pszFileName; //类静态字符串指针变量： 更多的例子，参见下面按照作用域讨论变量名一节。 1.1.5 主体 用于描述变量的上下文意义。 一般地，由首字母大写的一个或者多个单词构成，要求用英语作为描述语言。如：FileName，
软件开发规范：编码规范 C#编码规范 目标： 1. 安全：代码完成所需的功能之余,不要产生负作用，即要稳定可靠。 2. 易读: 类、实例、成员变量、成员函数的命名一目了然 3. 美观: 尽量统一项目组内人员的编程风格。 第一部分：命名 1. 命名原则 1) 所有的函数（变量/类/文件名）应该代表其实际的作用，应该使用有意义的单词或 多个词组合，但不要使用人名、项目组名。 2) 所有的函数（变量/类名）一律使用英文。 3) 使用多个单词时不需要使用连线(如下划线), 但对于全部大写的宏需要使用连 线。 4) 多个词组合较长时, 可以使用单词的缩写。 5) 不得使用非常相近的名字类表示几个不同含义的函数（变量/类）。 6) 命名时请考虑名字的唯一性和含义的准确性。 7) 使用项目组专用词汇来表达特定的含义(概念), 不得把专用词汇挪作他用。 2. 变量的命名 原则: 使用匈牙利命名法命名变量
1) 变量名一般由“类型修饰＋代表变量含意的英文单词或单词缩写”等部分 组成。 类型修饰(小写字母)： n: int，l: LONG/long， s: short，u: UINT，f: float b: bool，by: BYTE，ch: char， sz: char[],str: string 2) 针对异常捕获过程中的 Exception 变量命名，在没有冲突的情况下，统一 命名为 e；如果有冲突的情况下，可以重复 e，比如：ee。 3. 函数的命名 1) 使用动宾词组表达函数实际所作的事。 2) 同名的函数(重载函数)在功能上应该完全相同, 在参数上的差别也应一目 了然。 3) 不得出现名字非常相近但功能不同的函数. 如 CreatePage1(), CreatePage2()等。 4. 类命名 1) 名字应该能够标识事物的特性。 2) 名字尽量不使用缩写，除非它是众所周知的。 3) 名字可以有两个或三个单词组成，但通常不应多于三个。 4) 在名字中，所有单词第一个字母大写，缩写都要大写。 5.控件命名规则 5) 不要使用下划线字符 ( _ )。 1) 控件命名=Web控件缩写前缀+ “_” +变量名 控件 Label TextBox Button ListBox DropDownList 等等 缩写 lb_XXX tb_XXX Btn_XXX Lb_XXX Drd_XXX XXXXX 6. 文件命名 1) 文件起名要有实际意义。
Java语言编码规范 Prepared by 拟制Date 日期 yyyy-mm-dd Reviewed by 评审人Date 日期 yyyy-mm-dd Approved by 批准Date 日期 yyyy-mm-dd
Revision Record 修订记录
Table of Contents 目录 1. 范围.......................................................... 错误!未定义书签。 2. 规范性引用文件................................................ 错误!未定义书签。 3. 术语和定义.................................................... 错误!未定义书签。 4. 排版规范...................................................... 错误!未定义书签。. 规则 ............................................................. 错误!未定义书签。. 建议 ............................................................. 错误!未定义书签。 5. 注释规范...................................................... 错误!未定义书签。. 规则 ............................................................. 错误!未定义书签。. 建议 ............................................................. 错误!未定义书签。 6. 命名规范...................................................... 错误!未定义书签。. 规则 ............................................................. 错误!未定义书签。. 建议 ............................................................. 错误!未定义书签。 7. 编码规范...................................................... 错误!未定义书签。. 规则 ............................................................. 错误!未定义书签。. 建议 ............................................................. 错误!未定义书签。 8. JTEST规范..................................................... 错误!未定义书签。. 规则 ............................................................. 错误!未定义书签。. 建议 ............................................................. 错误!未定义书签。