项目编码规范编写指南

项目编码规范

1 命名规范

1）.包名采用域后缀倒置的加上自定义的包名，采用小写字母。

在部门内部应该规划好包名的范围，防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。

格式：

com.huawei.产品名.模块名称

com.huawei.部门名称. 项目名称

示例：

Relay模块包名 com.huawei.msg.relay

通用日志模块包名 com.huawei.msg.log

2）. 类名和接口使用类意义完整的英文描述，每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。

示例：

OrderInformation,

CustomerList,

LogManager,

LogConfig

3）. 方法名使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。

示例：

private void calculateRate();

public void addNewOrder();

4）. 方法中，存取属性的方法采用setter 和 getter方法，动作方法采用动词和动宾结构。格式：

get + 非布尔属性名()

is + 布尔属性名()

set + 属性名()

动词()

动词 + 宾语()

示例：

public String getType();

public boolean isFinished();

public void setVisible(boolean);

public void show();

public void addKeyListener(Listener);

5）.属性名使用意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。

示例：

private customerName;

private orderNumber;

private smpSession;

6). 常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用 final static 修饰。

示例：

public final static int MAX_VALUE = 1000;

public final static String DEFAULT_START_DATE = "2001-12-08";

7). 属性名可以和公有方法参数相同，不能和局部变量相同，引用非静态成员变量时使用 this 引用，引用静态成员变量时使用类名引用。

示例：

public class Person

{

private String name;

private static List properties;

public void setName (String name)

{

https://www.wendangku.net/doc/0f19360368.html, = name;

}

public void setProperties (List properties)

{

Person.properties = properties;

}

}

8).如果函数名超过15 个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。

示例：

getCustomerInformation() 改为 getCustomerInfo()

2 程序注释规范

1)、基本注释（必须加）

(a)类（接口）的注释

(b)构造函数的注释

(c)方法的注释

(d)全局变量的注释

(e)字段/属性的注释

备注：简单的代码做简单注释，注释内容不大于10个字即可，另外，持久化对象或VO 对象的getter、setter方法不需加注释。

2)、特殊必加注释

(a)典型算法必须有注释。

(b)在代码不明晰处必须有注释。

(c)在代码修改处加上修改标识的注释。

(d)在循环和逻辑分支组成的代码中加注释。

(e)为他人提供的接口必须加详细注释。

3 程序代码书写规范

书写规范即在编写代码过程中所使用的标准格式，主要包括空格的使用、括号的使用、缩近格式和其他一些内容。

1). 每行代码的长度推荐为80列，最长不得超过120列；折行以对齐为准。

2). 在类的成员函数内调用其他类的成员函数时，其他类的成员函数可做简短说明。

3). 函数入口参数有缺省值时，应注释说明。

4). else if 必须写在一行。

5). 与空格有关的各项规定。

①所有两目、三目运算符的两边都必须有空格。在单目运算符两端不必空格。但在‘.’、‘[’、‘]’等运算符前后，及‘&’（取地址）等运算符之后不得有空格。

② or、while、if 等关键词之后应有1个空格，再接‘(’，之后无空格；在结尾的‘)’前不得有空格。

③调用函数时，‘(’、‘)’前后不得有空格。

④类型强制转换时，‘(’‘)’前后不得有空格

6). 与缩进有关的各项规定

①缩进以 Tab 为单位。1 个 Tab 为 4 个空格

②下列情况，代码缩进一个 Tab: 函数体相对函数名及‘{’、‘}’。

if、else、for、while、do 等之后的代码。一行之内写不下，折行之后的代码，应在合理的位置进行折行。若有 + - * / 等运算符，则运算符应在上一行末尾，而不应在下一行的行首。

③下列情况，不必缩进：switch 之后的 case、default。在switch-case结构中，case语句距离switch 语句的开始应缩进一个TAB，每个case的程序体距离case的开始缩进一个TAB;

④所有的函数定义和函数定义的花括号都应位于第一列；

⑤所有成对的花括号都应出现在同一列，并与相应的控制语句同列，在对数组、类、和枚举类型的成员初始化时，同样遵循此规则；

代码编写规范

知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。

二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。

项目编码规范

项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）JS代码、HTML代码及数据库设计均应遵守这个规范。同时，也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解，方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法

产品图样和技术文件编号管理办法

产品图样和技术文件编号管理办法 1. 目的 1.1 为规范本公司产品设计管理，便于技术文件资料的标识、使用、表明技术文件和图样的不同类型和不同性质； 1.2 编号管理方法被有效地运用。 2. 范围 本公司所有的技术文件及图样，包括自行设计的产品图纸、零部件图纸、自行编写的技术条件、安装使用说明书、试制鉴定大纲、工艺文件，作业指导书等的编号。 3. 参考资料 JB/DQZ0133.9-1985 电工产品图样及技术文件编制导则产品图样及技术文件十进位分类编号法 4. 编号方法 4.1 图样和文件组成的形式 图样和文件的组成方式有两种：基本代号系统和补充代号系统。 4.1.1 基本代号系统：它由以下三部分组成，它适用于单一类型的产品或组成部分的图样或文件编号 a.企业代号 b.特征代号 c.序号 基本代号系统排列顺序如下： 序号 组 类特征代号 部 级特征代号 企业代号 4.1.2 补充代号系统：它由基本代号系统加上类型序号组成，它适用于具有多个类型的产品或组成部分的图样或文件编号 补充代号系统排列顺序如下

型序号 特征代号 特征代号 4.2 编号组成形式的确定原则 4.2.1 企业代号 本公司的企业代号为“YCD”。 4.2.2 特征代号 特征代号由四个阿拉伯数字组成，自左至右顺次表示级、部、类、组。为了能更明显地区分对象的级别，规定将级的代号与企业代号写在一起（产品及其组成部分以及技术文件的分级详见表1）。部、类、组的代号写在企业代号之右。 4.2.3 序号 序号采用四位阿拉伯数字，用以确定在该特征代号范围内的具体编号顺序，称登记序号。4.2.4 类型序号 对于某一产品或组成部分（组件、部件、零件）在确定其特征代号后，因又不是单一的类型（品种、规格），而是多个类型，在对图样或文件进行编号时，应采用补充代号系统形式，类型序号应按类型数量的多少而定，从阿拉伯数字“1”开始，按数字的连续、递增顺序编定。 4.2.5 编号时，应在企业代号、特征代号、序号、类型序号间用小圆点“．”隔开（小圆点点在右下角）。 4.2.6 每一产品及其组成部分都应以一物一号为原则绘成标准幅面的单份图样并编写代号。对不同对象的图样不得使用相同的代号，反之，相同的图样又不得使用不同的代号。也就是说每份图样或文件必须有其专用的代号。 4.2.7 两种编号形式的选择方法 4.2.7.1 单一类型的产品、组件、部件、零件的图样应单独绘制，这种图样的代号应按基本代号系统来编定。 4.2.7.2 对于一种产品，因具有多个类型的整件、组件、部件、零件，其外形完全相同，而尺寸却不一样，它们在绘制成单独的图样时常常绘制成表格图，这种图样应按补充代号系统来进行编号。 4.2.8 两种编号组成形式示例

程序代码注释编写规范

百度文库- 让每个人平等地提升自我 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、使用可以准确说明变量/字段/类的完整的英文描述符。例如，采用类似firstName，grandTotal 或CorporateCustomer 这样的名字。禁止使用一些象x1，y1 或fn 这样的名字很简短，输入起来容易，辨别含义困难的命名，使得代码难以理解、维护和改进。 2、采用领域的术语命名。如果用户称他们的“客户”(clients) 为“顾客”(customers)，那么就采用术语Customer 来命名这个类，而不用Client。保证命名使用行业或领域里已经存在着很完美的术语，避免生造词汇。

3、采用大小写混合，提高名字的可读性。一般应该采用小写字母，但类名、接口名以及任何非初始单词的第一个字母要大写，一些特殊场合以具体规范为准。 4、尽量少用缩写，但如果一定要使用，必须使用一个统一遵守的缩写，并且在使用时保持一致。例如，如果要对单词“number”采用缩写，那么可从nbr，no 或者num 中选取一个，采用其中一个（具体是哪个倒无所谓），并且只使用这一种形式。 5、避免使用长名字（最好不超过20 个字母）。避免类似如PhysicalOrVirtualProductOrService 之类的超长命名。 6、避免使用相似或者仅在大小写上有区别的名字。例如，不应同时使用变量名persistentObject 和persistentObjects，以及anSqlDatabase 和anSQLDatabase。 7、避免使用下划线作为名字的首末字母。以下划线为首末字母的名字通常为系统保留，除预处理定义之外，一般不用作用户命名。 八、编码注释准则： 1、必须明确注释的重要性。如果你的程序不值得注释，那么它也不值得运行。 2、注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。如果不能被他人所理解，则代码的注释是失败的注释，等同于无注释。 3、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。

项目编码规则

□机密文件■管制文件□一般文件 主题： 项目编码规则 文件编码： 版本：V5.2 机种：———— 生效日期：发行日生效PAGE 0 OF 13 （变更历史记录）： 变更次数变更内容变更人变更日期 0 首次发行,第一版1999.12.5 1 物料编码规则维护2000.5.33 2 项目编码规则维护，变更码长和分类、取消延申码，2001.2.9 3 项目编码规则维护, 2001.6.25 4 项目编码规则维护, 2002-4-29 5 项目编码规则维护, 2002-5-16 6 项目编码规则维护,数码产品2002-8-13 7 项目编码规则维护,笔记本2003-3-7 8 项目编码规则维护,笔记本编码2003-12-29 9 根据现有业务流程进行版本升级徐斐2004-2-28 10 项目编码规则维护,PTO编码徐斐2004-5-30 分发部门□研发中心□生产管理□财务□行政部 □采购□市场□品管部□信息管理部□商务□计划物控□ □客服□产品销售□□ 会签部门 （部门长） 批准审核拟稿TCL电脑科技（深圳）有限公司

目录 1 目的. (3) 2 范围. (3) 3 权责. (3) 3.1信息管理部 (3) 3.2研发部 (3) 3.3产品管理部 (3) 3.4其它部门 (3) 3.5 TCL万维科技(深圳)有限公司 .......................................................................... 错误!未定义书签。4定义 . (3) 5 TCL电脑科技有限责任公司项目编码规则 (4) 5.1 成品编码规则 (4) 5.2零部件的编码规则 (6) 5.3 PC主机电脑及外设所用项目的选项类项目编码规则 (10) 5.4 笔记本主机电脑及外设所用项目的选项类项目编码规则 (12) 5.5固定资产编码规则 (17) 5.6办公用品编码规则 (18) 5.7促销品编码规则 (18) 5.8客服的服务用品编码规则 (18) 5.9外协项目的编码规则 (18) 5.9工程物料编码规则 (18) 6 TCL万维科技(深圳)有限公司项目编码规则 (18) 7项目编码规则的维护. (19) 8相关文件. (19)

信息技术部各类文档命名规范.doc

文档索引：NIAT-GF-MM-1213-04 宁波东大智能 文档命名规范 宁波柴天佑院士工作室 宁波东大自动化智能技术有限公司 信息技术部 2010年12月13日

文档修订 抄送人：项目经理、客户经理、客户代表、项目组成员、SCCB（在项目实际应用时最好写明抄送人的姓名）

目录 一、部门规范 (4) 1.1数据库设计规范文档命名 (4) 1.2代码编写规范文档命名 (4) 1.3界面风格规范文档命名 (4) 1.4文档编写规范命名 (4) 1.4.1需求分析文档命名 (4) 1.4.2编码设计文档命名 (5) 1.4.3数据库设计文档命名 (5) 1.4.4操作需求文档命名 (5) 1.4.5功能设计文档命名 (5) 1.4.6软件详细设计文档命名 (6) 1.4.7软件测试文档命名 (6) 1.5软件视频命名规范 (6) 1.6用户手册文档命名 (6) 二、部门管理规范 (7) 2.1下厂任务单命名 (7) 2.2下厂总结报告命名 (7) 2.3软件功能验收文档命名 (7)

一、部门规范 1.1数据库设计规范文档命名 软件功能开发过程中，要遵循公司的数据库设计规范文档。数据库设计规范规范文档的命名，遵循以下格式：公司简称+规范编号+数据库代号+编写日期+ 举例：NIAT-GF-SJK-121301 1.2代码编写规范文档命名 软件功能开发过程中，要遵循公司的代码编写规范文档。代码编写规范文档的命名，遵循以下格式：公司简称+规范编号+代码代号+编写日期+序列号，中 举例：NIAT-GF-DM-121301 1.3界面风格规范文档命名 软件功能开发过程中，开发的软件要进行界面风格的统一，要遵循公司的界面风格规范文档。界面风格规范文档的命名，遵循以下格式：公司简称+规范编 举例：NIAT-GF-JM-121301 1.4文档编写规范命名 1.4.1需求分析文档命名 软件功能开发之前，要对用户的要求进行需求分析，编写需求分析文档。需求分析文档的命名，遵循以下格式：模块编号+需求代号+编写日期+序列号，中 举例：M2-XQ-1208-01

项目编码管理规定

项目编码管理规定 1 目的 为了规范集团项目编码管理，明确各编码规则的使用范围，特制订本规则。 2 适用范围 本规则适用于集团公司各单位及所全资子公司，合资公司参照执行。 3 项目编码规则 项目编码长度为12位，根据项目性质的不同，分别制订不同的编码规则。 3.1营销项目编码规则 3.1.1营销项目已立项后，由市场管理部下发唯一的项目名称及项目编码；营销项目转化为施工项目时，延用营销项目的名称和编码。 3.1.2参考《集团公司营销项目立项及管理办法》(ZD-ZH-030/V0-2013)，具体方法如下： 3.1.3 项目编码共12位，名称标准为“产业单位+客户单位/区域+产品/服务内容+年份/批次”a）第一至二位为字母，代表产业单位，取自单位名称拼音； b）第三至四位为字母：代表销售区域/办事处，取自区域/办事处名称拼音； c）第五至八位为字母：代表项目主要产品及服务内容，取自集团产品及服务目录三级、四级目录拼音，产品目录为三字内容时，四位字母代码第一位为大写字母“O”，项目服务内容为多个产品目录组合内容时，以主要产品目录名称编制； d）第九至十二位为数字：代表年份及批次，以上字段相同时加以区别。

3.2 关联交易项目编码规则 3.2.1关联交易项目编码规则为：“营销项目编码（复制）”+“ERP法人代码（3位）”+“ERP 事业部代码（2位）” 3.2.2复制的营销项目编码与ERP法人代码（3位）之间用“-”符号连接 3.3公共费用项目编码规则 3.3.1公共费用项目使用范围 a）产业单位无法按项目进行归集，需要按一定原则进行分摊的成本； b）职能单位发生的费用； c）营销单位无法归集到营销项目的费用。 3.3.2公共费用项目统一使用四个零“0000”。 3.4虚拟项目编码规则 3.4.1虚拟项目使用范围 a）以生产、加工、制造为主要业务的单位，包括管材集团、油气井工具中心、陶粒公司；b）以非施工类服务为主要业务的单位，包括软件公司、集团总部。 3.4.2虚拟项目统一使用十二个零“000000000000”。 3.5期初上线项目编码规则 3.5.1期初上线项目使用范围 PA项目期初上线时期，未进行营销立项的项目使用 3.5.2国内期初上线项目统一使用十二个九“999999999999” 3.5.3国际期初上线项目按法人分别建立，编码规则为“ERP法人代码（3位）”+“9个0” 4 子项目编码规则 子项目编码长度为7位，根据子项目的性质不同，制订不同的编码规则。 4.1施工子项目编码规则 4.1.1施工子项目编码规则为“事业部唯一识别码（1位）”+“年份（2位）”+“流水号（4 2

技术资料管理办法

1.总则 1.1为建立、健全公司技术档案工作，完整地保存和科学地管理公司的技术档案，充分发挥技术档案在公司建设和发展中的作用，更好地为公司各部门服务，特制订本管理制度。 1.2加强技术文件和资料的控制，防止失效或作废的技术文件和资料被误用。 1.3 定型技术文件原件及其他重要文件（如合同、协议、公司对外发放红头文件等）由综合部统一归档；技术部留存复印件，未定型技术文件由技术部统一管理。 1.4建立、健全技术档案工作，达到全公司技术档案的完整、准确、系统、安全和有效利用。 2.技术文件资料的归档 2.1 每一个技术项目完成或告一段落后，都要有完整、准确、系统的技术文件资料，将所形成的技术文件资料加以系统的整理，由技术部经理审查后及时向公司综合部移交归档。 2.2各部门或技术人员在移交技术档案或技术文件资料时，交接双方应按规定办理移交手续，签字归档备查。 2.3 归档文件和资料的种类

2.3.1产品文件和资料 开发协议/技术协议、设计任务书、产品图（包括二维、三维图）、清单（材料、采购、图纸）、包装图、技术标准、设计更改通知单、设备文件（说明书、操作规程）、试验大纲、实验报告等。 2.3.2外来技术文件和资料 外来技术文件和资料包括： a、外来标准（采用的企业、行业、国家、国际标准等）； b、顾客或供应商提供的资料（图纸、技术要求、顾客工程规范、清单等）； c、顾客提供的样件。 2.3.3工艺文件和资料 控制计划、过程流程图、包装规范、特殊特性清单、PFMEA/DFMEA、作业指导书（打标、装配、检验、包装）等。 2.3.4办公文件及资料 规章制度、通知、会议记录、培训资料等。 3.技术档案的保管 3.1 综合/技术档案室应对技术档案进行分类、编目、登记、统计，编制目录，注明移交文件/资料名称、份数、时间、交接人，并备注用途。做到定位存放，妥善保管，方便利用。 3.2认真执行技术档案的保管检查制度，综合/技术部应在每年年底对档案联合全面检查、清理一次，做到帐档一致。并于12月30日以

Java代码编写规范(参考)

命名规范： 1.所有的标识都只能使用ASCII字母（A-Z或a-z）、数字（0-9）和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词，采用大小写混合的方式，每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组，采用大小写混合的方式，第一 个单词的首字母小写，其后单词的首字母大写。 6.变量名的第一个字母小写，任何中间单词的首字母大写，变量名 应简短且可以顾名思义，易于记忆。避免单个字符的变量名，除非是一次性的临时变量。 7.常量的声明应该全部大写，每个单词之间用”_”连接。 注释规范： 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/，而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释，其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释（main除外）。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。

缩进排版规范： 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范： 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范： 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范： 1.每行至少包含一条简单语句。 2.在return语句中，返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中，避免因使用3个以上变量， 而导致复杂度提高。 5.当switch的一个case顺着往下执行时（因为没有break），通常 应在break语句的位置添加注释。

项目开发及编码规范

项目开发规范文档修订历史记录

1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册

3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。

软件代码编写规范

? 软件销售代理合同范本软件代码编写规范 草稿 2005.2

? 软件销售代理合同范本 1 命名规则 https://www.wendangku.net/doc/0f19360368.html,命名规则 一致的命名模式是托管类库中可预知性与可发现性最重要的元素之一。对这些命名指南广泛的使用和理解将消除许多最常见的用户问题。本主题提供.NET Framework 类型的命名指南。对于每个类型，还应该注意关于大写样式、区分大小写和措词的一些通用规则。 1.1.1大写样式 描述用于在类库中命名标识符的Pascal 大小写、Camel 大小写和全部大写样式。 使用下面的三种大写标识符约定。 Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如： B ack C olor Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如： b ack C olor 大写 标识符中的所有字母都大写。仅对于由两个或者更少字母组成的标识符使用该约定。例如： System.IO System.Web.UI 可能还必须大写标识符以维持与现有非托管符号方案的兼容性，在该方案中所有大写字母经常用于枚举和常数值。一般情况下，在使用它们的程序集之外这些字符应当是不可见的。 下表汇总了大写规则，并提供了不同类型的标识符的示例。 标识符大小写示例 类Pascal AppDomain 枚举类型Pascal ErrorLevel 枚举值Pascal FatalError 事件Pascal ValueChange 异常类Pascal WebException 注意总是以Exception后缀结尾。 只读的静态字段Pascal RedValue 接口Pascal IDisposable 注意总是以I 前缀开始。 方法Pascal ToString 命名空间Pascal System.Drawing 参数Camel typeName 属性Pascal BackColor

项目编码规范编写指南

项目编码规范 1 命名规范 1）.包名采用域后缀倒置的加上自定义的包名，采用小写字母。 在部门内部应该规划好包名的范围，防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。 格式： com.huawei.产品名.模块名称 com.huawei.部门名称. 项目名称 示例： Relay模块包名 com.huawei.msg.relay 通用日志模块包名 com.huawei.msg.log 2）. 类名和接口使用类意义完整的英文描述，每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。 示例： OrderInformation, CustomerList, LogManager, LogConfig 3）. 方法名使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。 示例： private void calculateRate(); public void addNewOrder(); 4）. 方法中，存取属性的方法采用setter 和 getter方法，动作方法采用动词和动宾结构。格式： get + 非布尔属性名() is + 布尔属性名() set + 属性名() 动词() 动词 + 宾语() 示例： public String getType(); public boolean isFinished(); public void setVisible(boolean); public void show();

public void addKeyListener(Listener); 5）.属性名使用意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。 示例： private customerName; private orderNumber; private smpSession; 6). 常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用 final static 修饰。 示例： public final static int MAX_VALUE = 1000; public final static String DEFAULT_START_DATE = "2001-12-08"; 7). 属性名可以和公有方法参数相同，不能和局部变量相同，引用非静态成员变量时使用 this 引用，引用静态成员变量时使用类名引用。 示例： public class Person { private String name; private static List properties; public void setName (String name) { https://www.wendangku.net/doc/0f19360368.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例： getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释（必须加）

文件编号及格式编制规定

文件编号： 文件编号及格式编制规定 版次： 受控状态：

1.0目的 对本公司质量管理体系文件、记录进行编号和格式规定，确保本公司质量管理体系文件的一致性。 2.0适用范围 适用于本公司所有部门 3.0职责 3.1技术质量部负责编制质量管理体系文件、记录编号及格式规定，审核质量管理体系文件、 记录编号及格式规定。 4.0工作程序 4.1质量手册的编号规定 HC / QM 质量手册 XX 4.2程序文件的编号规定 HC / QP —×× 程序文件 XX 4.3管理及操作性文件编号规定 HCYL—×××—××—××× 文件流水号 职能代号（见4.3.1） 文件分类（见4.3.3） 医疗 4.3.1 职能代号 “JZ”——技术质量 “SC”——生产采购

“SB”——设备 “RL”——人力资源 “BG”——办公室 “YC”——营销 “JL”——计量（监视和测量设备） 4.3.2文件分类 “SOP”——标准操作规程 “SMP”——标准管理规程 “STP”——技术、质量标准 “SOR”——记录 “CE”——CE技术文件 “QR”——确认 “YZ”——验证 4.4产品确认资料编号 HCYL –YZ/QR /×××—××× 确认或确认流水号 产品名称首位字母（大写三位） 验证/确认资料 医疗 4.4.1第一个确认资料编号为001，第二个验证/确认资料编号为002，……依次排序表示 如：灭菌确认为公司第一个验证/确认资料为001，包装确认为第二个验证/确认资料为002，……依次排序表示 4.4.2方案为每个验证/确认的001，报告为每个验证/确认的002。 如：导尿包灭菌验证如果为公司的第一个验证，验证方案编号为HCYL-YZ/DNB-001-A，验证报告为HCYL-YZ/DNB-001-B；导尿包包装验证如果为公司的第二个验证，验证方案编号为HCYL-YZ/DNB-002-A，确认报告为HCYL-YZ/DNB-002-B，……。 4.4.3验证/确认版次、修订按管理及操作性文件执行。 4.5外来文件的编号 如果原文件有编号，引用原文件编号，如无编号按下列编号格式执行。 ×××—××××—××× 流水号

安全代码编写规范

安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。

四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对