项目代码编程规范
1.应用范围
本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）JS代码、HTML代码及数据库设计均应遵守这个规范。同时，也可作为其它项目的参考。
2.设计类和方法
2.1. 创建具有很强内聚力的类
方法的重要性往往比类的重要性更容易理解，方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。
之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。
类应该用来将相关的方法组织在一起。
当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。
大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。
创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。
2.2. 创建松散连接和高度专用的方法
2.2.1.使所有方法都执行专门的任务
每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。
创建专用方法有许多好处。首先调试将变得更加容易。
2.2.2.尽量使方法成为自成一体的独立方法
当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法
会使调试和修改变得比较困难，因为它牵涉到更多的因素。松散连接的方法优于紧密连接的方法，但你不可能使每个方法都成为独立的方法。
若要使方法具备较强的独立性，方法之一是尽量减少类变量。
创建方法时，设法将每个方法视为一个黑箱，其他例程不应要求了解该方法的内部工作情况，该方法也不应要求了解它外面的工程情况。这就是为什么你的方法应依靠参数而不应依靠全局变量的原因。
创建专用方法时，请考虑下列指导原则：
1)将复杂进程放入专用方法。如果应用程序使用复杂的数学公式，请考虑将每个公式放入它自己的方法中。这样使用这些公式的其他方法就不包含用于该公式的实际代码。这样也可以更容易发现与公式相关的问题。
2)将数据输入/输出（I/O）放入专用方法。
3)将专用方法中可能要修改的代码隔离。如果你知道某个进程经常变更，请将这个多变的代码放入专用方法，以便以后可以更容易的进行修改，并减少无意中给其他进程带来问题的可能性。
4)将业务规则封装在专用方法中。业务规则常属于要修改的代码类别，应与应用程序的其余部分隔开。其他方法不应知道业务规则，只有要调用的方法才使用这些规则。
2.3. 设计类和方法时，要达到下列目的：
1)创建更加容易调试和维护的方法
2)创建具有强大内聚力的类
3)创建高度专用的方法
4)创建松散连接的方法
5)尽量使方法具有独立性
6)提高方法的扇入性
7)降低方法的扇出性
2.4. 编程原则
2.4.1.为方法和类赋予表义性强的名字
为了使代码更加容易理解，最容易的方法之一是为你的方法赋予表义性强的名字。函数名DoIt、GetIt的可读性很难与CalculateSalesTax、 RetrieveUserID相比。
由缩写方法名组成的代码很难理解和维护，没有理由再这样做了。
给方法正确的命名，可使程序工程的调试和维护工作大大的改观。请认真对待方法命名的工作，不要为了减少键入操作量而降低方法的可理解度。
实际应用举例：
1)给方法命名时应大小写字母混合使用。如果句子全使用大写字母，那么阅读起来就非常困难，而大小写字母混合使用的句子，阅读起来就很容易。
2)定义方法名时不要使用缩写。如果你认为应用程序中的某些工程应使用缩写，那么请将这些情况加上注释，并确保每个人在所有时间内都使用这些缩写。决不要在某些方法中对某些单词进行缩写，而在别的方法中却不使用缩写。
3)定义方法名要统一使用英文单词或者计算机专业英语，要做到见名知意。
2.4.2.创建方法时，始终都应显式地定义它的作用域。
1) 如果你真的想创建一个公用方法，请向代码阅读者说明这一点。
2) 通过为每个方法赋予一个明确定义的作用域，可以减少代码阅读者需要投入的工作量。应确保你为方法赋予最有意义的作用域。如果一个方法只被同一类中的另一个方法调用，那么请将它创建成私有方法。如果该方法是从多个类中的多个方法中调用，请将该说明为公用方法。
2.4.
3.用参数在方法之间传递数据
应尽量避免使用类变量。一般来说，变量的作用域越小越好。为了减少类变量，方法之一是将数据作为参数在不同方法之间传递，而不是让方法共享类变量。
1)为每个参数指定数据类型。
2)始终要对数进行检验，决不要假设你得数据没有问题。程序员常犯的一个错误是在编写方法时假设数据没有问题。在初始编程阶段，当编写调用方法时，这样的假设并无大碍。这时你完全能够知道什么是参数的许可值，并按要求提供这些值。但如果你不对参数的数据进行检验，那么下列情况就会给你带来很大麻烦：另外某个人创建了一个调用方法，但此人不知道允许的值；你在晚些时候添加了新的调用方法，并错误的传递了坏数据。
2.4.4.其他编程建议
1.注意释放资源，如文件关闭，数据库操作后关闭ResultSet, Statement, Connection等，其
他涉及IO操作的如:各种Reader，Writer，InputStream，OutputStream等等。
2.使用StringBuffer 对象
在处理String 的时候要尽量使用StringBuffer 类，StringBuffer 类是构成String 类的基
础。String 类将StringBuffer 类封装了起来，（以花费更多时间为代价）为开发人员提供
了一个安全的接口。当我们在构造字符串的时候，我们应该用StringBuffer 来实现大部
分的工作，当工作完成后将StringBuffer 对象再转换为需要的String 对象。比如：如果
有一个字符串必须不断地在其后添加许多字符来完成构造，那么我们应该使用
StringBuffer 对象和它的append() 方法。如果我们用String 对象代替StringBuffer 对象
的话，会花费许多不必要的创建和释放对象的CPU 时间。
3.避免太多的使用synchronized 关键字
避免不必要的使用关键字synchronized，应该在必要的时候再使用它，这是一个避免死
锁的好方法。必须使用时，也尽量控制范围，最好在块级控制。
4.避免使用java.util.Vector 等那些在jdk1.3前就有的集合类
因为"Unlike the new collection implementations, Vector is synchronized."，所以使用
java.util.Vector类在性能上会有所减低。
5.尽量使用接口而不是一个具体的类
比方如下需求，给定一个SQL语句，返回一个对象的列表，实现中用java.util.ArrayList
实现，于是定义方法为：
public java.util.ArrayList getObjectItems(String sql)
上面的方法存在一个问题，当getObjectItems内改用Vector或LinkedList实现，外部类
必须做相应更改。一个更好的方法是定义返回值为java.util.AbstractList更合适：
public java.util.AbstractList getObjectItems(String sql)
这样即使更改实现，外部类也不必做相应更改。
6.避免使用索引来调用数据库中间层组件返回的结果集
如：
for(int i=1; i<=dt.getRowCount(); i++)
{ String field1 = dt.getField(i, 0).toString(); ……}
而应用字段名来存取结果集：
for(int i=1; i<=dt.getRowCount(); i++)
{ String field1 = dt.getField(i, "field1").toString(); ……}
这样在数据库设计更改或查询的SQL语句发生变化时，不会影响到程序的执行。
3.命名约定
所有变量的定义应该遵循匈牙利命名法，由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。
3.1. 工程的命名
3.1.1.工程的命名
直接使用projectname.
3.1.2.工程目录的分配(参照各类开发工具的设置)
1.设计文档(design)：design
2.源代码(source)：src.
3.引用的库文件(library)：lib
4.生成的代码(class)：classes
5. 生成的文档(document)：docs
3.2. 包
3.2.1.约定
●根级目录以com.**开头！
●各项目名称为下一级包！本级目录为项目的控制类所在(即：实现主要流程的类和涉及项目系统
管理的类)。
●再下级的主要并列目录名：
1)Cloudframework 云存储开发框架包
2)Cngi 具体的应用系统名
●全部小写
●使用英语单词，不要使用汉语拼音
●标识符用点号分隔开来
3.2.2.举例
3.3. 类，接口
3.3.1.约定
●类的名字应该使用名词
●使用英语单词，不要使用汉语拼音
●每个单词首字母应该大写
●避免使用单词的缩写，除非它的缩写已经广为人知，如HTTP
●实现类一般采用接口类名+Impl来展现
3.3.2.举例
Class Hello;
Class HelloWorld ;
Interface Apple;
Class AppleImpl implements Apple;
3.4. 方法
3.4.1.约定
●第一个单词一般是动词。
●使用英语单词，不要使用汉语拼音
●第一个单词是小写，但是中间单词的首字母是大写。
●如果方法返回一个成员变量的值，方法名一般为get+成员变量名，如若返回的值是bool
变量，一般以is作为前缀。
●如果方法修改一个成员变量的值，方法名一般为：set+成员变量名。
3.4.2.举例
getName();
setName();
isFirst();
3.5. 变量
3.5.1.约定
●单词的首字母大写；但是首个单词字母都必须小写
●使用英语单词，不要使用汉语拼音
●不要用_或&作为第一个字母。
●尽量使用短而且具有意义的单词。
●单字符的变量名一般只用于生命期非常短暂的变量。i,j,k,m,n一般用于int/integers；
c,d,e一般用于characters。
●如果变量是集合，则变量名应用复数。
●boolean/ Boolean类型的使用is前缀
●命名组件采用匈牙利命名法。
3.5.2.举例
String fileName;
int[] students;
int i;
int n;
boolean isPass;
3.6. 常量
3.6.1.约定
●所有常量名均全部大写，单词间以‘_’隔开。
●使用英语单词，不要使用汉语拼音
●特殊情况下可以使用全拼，但是请注释说明
3.6.2.举例
int I_MAX_NUM;
3.7. jsp,html,xml等文件
3.7.1.约定
●使用英语单词，不要使用汉语拼音
●首单词小写，其它单词首字母应该大写
●避免使用单词的缩写，除非它的缩写已经广为人知，如HTTP
3.7.2.举例
register.jsp 注册，新增
view.jsp 查询页面视图
infoMaintain.jsp 维护页面视图
dateView.jsp 按日期查询页面视图
3.8. 数据库表、视图
3.8.1.约定
●全部小写
●以“_”分隔单词
●尽量表义
●使用英语单词，不要使用汉语拼音
●主表用“info”表示，
●每个表名都加“t_”用来识别为表对象
3.8.2.举例
t_user_info 缩写ui 用户主表
t_user_type 用户类型字典表
3.9. 数据库字段
3.9.1.约定
●首单词小写，其他单词首字母大写
●使用英语单词，不要使用汉语拼音
3.9.2.举例
id
name
userType
userId
4.使用常量
4.1. 常数很容易在数据输入时出错
常数存在的主要问题之一是你很容易在键入数字时出错，从而颠倒了数字的位置。例如，当你键入数字10876时，很容易的键入10867或18076。与处理变量和保留字的方法不同，编译器并不在乎颠倒了位置和不正确的数字，有时简单的错误造成的问题不会立即表现出来，而当问题表现出来时，它们会以随机的计算错误的形式出现，这些错误很难准确定位。用常量来取代常数时，编译器将在编译时检查常量的有效性。如果常量不存在，编译器便将这一情况通知你，并拒绝进行编译，这可以消除错误键入的数字带来的问题，只要常量拥有正确的值，使用该常量的所有代码也有使用该正确值。
4.2. 常数很难不断更新
4.3. 常量使代码更容易阅读
使用常量后，得到的一个额外好处是可使创建的代码更容易阅读。常数很不直观。也许你对常数非常了解，但其他人则根本看不明白。通过合理的给常量命名，使用这些常量的代码就变得比较直观了，更容易阅读。
为常量赋予较宽的作用域，这与使用变量时的情况不同。在一个应用程序中你决不应该两次创建相同的常量。如果你发现自己复制了一个常量，请将原始的常量说明转至较宽的作用域，直到该常量可供引用它的所有方法为止。
5.变量
5.1. 定义有焦点的变量
用于多个目的的变量称为无焦点（多焦点）的变量。无焦点变量所代表的意义与程序的执行流程有关，当程序处于不同位置时，它所表示的意义是不固定的，这样就给程序的可读性和可维护性带来了麻烦。
5.2. 只对常用变量名和长变量名进行缩写
如果需要对变量名进行缩写时，一定要注意整个代码中缩写规则的一致性。例如，如果在代码的某些区域中使用Cnt，而在另一些区域中又使用Count，就会给代码增加不必要的复杂性。
变量名中尽量不要出现缩写。
5.3. 使用统一的量词
通过在结尾处放置一个量词，就可创建更加统一的变量，它们更容易理解，也更容易搜索。例如，请使用strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。
量词列表：First、Last、Next、Prev、Cur
量词后缀
说明
First 一组变量中的第一个
Last 一组变量中的最后一个
Next 一组变量中的下一个变量
Prev 一组变量中的上一个
Cur 一组变量中的当前变量
5.4. 使用肯定形式的布尔变量
给布尔变量命名时，始终都要使用变量的肯定形式，以减少其它开发人员在理解布尔变量所代表的意义时的难度。
5.5. 为每个变量选择最佳的数据类型
这样即能减少对内存的需求量，加快代码的执行速度，又会降低出错的可能性。用于变量的数据类型可能会影响该变量进行计算所产生的结果。在这种情况下，编译器不会产生运行期错误，它只是迫使该值符合数据类型的要求。这类问题极难查找。
5.6. 尽量缩小变量的作用域
如果变量的作用域大于它应有的范围，变量可继续存在，并且在不再需要该变量后的很长时间内仍然占用资源。
它们的主要问题是，任何类中的任何方法都能对它们进行修改，并且很难跟踪究竟是何处进行修改的。
占用资源是作用域涉及的一个重要问题。对变量来说，尽量缩小作用域将会对应用程序的可靠性产生巨大的影响。
6.代码的格式化
6.1. 对代码进行格式化时，要达到的目的
1.通过代码分割成功能块和便于理解的代码段，使代码更容易阅读和理解；
2.使用空行和注释行，将程序中逻辑上不相关的代码块分开。比如：变量声明部分和代码语句间的分隔；较长的方法中，完成不同功能的代码块间的分隔。要避免出现逻辑上混乱的分隔，如：某一逻辑功能代码块中间用空行进行了分隔，但是在相邻功能代码块之间却没有分隔，这样会给程序阅读者造成错觉。
3.减少为理解代码结构而需要做的工作；
4.使代码的阅读者不必进行假设；
5.使代码结构尽可能做到格式清楚明了。
6.2. 编程原则
1.不要将多个语句放在同一行上。不论是变量声明，还是语句都不要在一行上书写多个。
2.缩进后续行
当你将变量设置为某个值时，所有后续行的缩进位置应与第一行的变量值相同；
当你调用一个方法时，后续行缩进到第一个参数的开始处；
当你将变量或属性设置为等于表达式的计算结果时，请从后面分割该语句，以确保该表达式尽可能放在同一行上。
3.在if语句后缩进；
在else语句后缩进
在switch语句后缩进
在case语句后缩进
在do句后缩进
已经用行接续符分割的语句的各个行要缩进
对从属于行标注的代码进行缩进。
4.在执行统一任务的各个语句组之间插入一个空行。好的代码应由按逻辑顺序排列的进程或相关语句组构成。
7.代码的注释
7.1. 使用代码注释的目的
1.文字说明代码的作用(即为什么要用编写该代码,而不是如何编写);
2.确指出该代码的编写思路和逻辑方法;
3.方便人们注意到代码中的重要转折点;
4.使代码的阅读者不必在他们的头脑中仿真运行代码的执行方法.
5.说明代码的使用条件。
7.2. 编程原则
7.2.1.用文字说明代码的作用:
简单的重复代码做写什么,这样的注释几乎不能给注释增加什么信息.如果你使用好的命名方法来创建直观明了的代码那么这些类型的注释绝对增加不了什么信息.
7.2.2.如果你想违背好的编程原则,请说明为什么
有的时候你可能需要违背好的编程原则，或者使用了某些不正规的方法，.遇到这种情况时,请用内部注释来说明你在做什么和为什么要这样做。
技巧性特别高的代码段，一定要加详细的注释，不要让其他开发人员花很长时间来研究一个高技巧但不易理解的程序段。
7.2.3.用注释来说明何时可能出错和为什么出错
7.2.4.在编写代码前进行注释
给代码加注释的方法之一是在编写一个方法前首先写上注释.如果你愿意,可以编写完整句子的注释或伪代码.一旦你用注释对代码进行了概述,就可以在注释之间编写代码.
7.2.5.在要注释的代码前书写注释
注释一定出现在要注释的程序段前，不要在某段程序后书写对这段程序的注释，先看到注释对程序的理解会有一定帮助。
如果有可能，请在注释行与上面代码间加一空行。
7.2.6.纯色字符注释行只用于主要注释
注释中要分隔时，请使用一行空注释行来完成，不要使用纯色字符，以保持版面的整洁、清晰。
7.2.7.避免形成注释框
用星号围成的注释框，右边的星号看起来很好,但它们给注释增加了任何信息吗?实际上这会给编写或编辑注释的人增加许多工作。
7.2.8.增强注释的可读性
注释是供人阅读的，而不是让计算机阅读的。
1)使用完整的语句。虽然不必将注释分成段落（最好也不要分成段落），但你应尽量将注释写成完整的句子。
2)避免使用缩写。缩写常使注释更难阅读，人们常用不同的方法对相同的单词进行缩写，这会造成许多混乱，如果必须对词汇缩写，必须做到统一。
3)将整个单词大写，以突出它们的重要性。若要使人们注意注释中的一个或多个单词，请全部使用大写字母。
7.2.9.对注释进行缩进，使之与后随的语句对齐。
注释通常位于它们要说明的代码的前面。为了从视觉上突出注释与它的代码之间的关系，请将注释缩进，使之与代码处于同一个层次上。
7.2.10.为每个方法和类赋予一个注释标头
每个方法都应有一个注释标头。方法的注释标头可包含多个文字项，比如输入参数、返回值、原始作者、最后编辑该方法的程序员、上次修改日期、版权信息。
7.2.11.当行尾注释用在上面这种代码段结构中时，它们会使代码
更难阅读。
使用多个行尾注释时（比如用于方法顶部的多个变量说明），应使它们互相对齐。这可使它们稍容易阅读一些。
7.2.12.何时书写注释
1)请在每个if语句的前面加上注释。
2)在每个switch语句的前面加上注释。与if语句一样，switch语句用于评估对程序执行产生
影响的表达式。
3)在每个循环的前面加上注释。每个循环都有它的作用，许多情况下这个作用不清楚直观。
7.3. 注释那些部分
7.3.1.类
类的目的
参数：参数类型参数用来做什么
任何约束或前提条件
已知的问题
类的开发/维护历史
注释出采用的不变量
并行策略
编译单元
每一个类/类内定义的接口，含简单的说明
文件名和/或标识信息
版权信息
7.3.2.接口
目的
它应如何被使用以及如何不被使用
7.3.3.类属性
用处
目的
不同值的含义
7.3.4.成员函数注释
成员函数做什么以及它为什么做这个
哪些参数必须传递给一个成员函数
成员函数返回什么
已知的问题
任何由某个成员函数抛出的异常
可见性决策
成员函数是如何改变对象的
包含任何修改代码的历史
如何在适当情况下调用成员函数的例子适用的前提条件和后置条件
7.3.5.成员函数内部注释
控制结构
代码做了些什么以及为什么这样做
局部变量
难或复杂的代码
处理顺序
对if-else语句的各个条件，要说明其含义。
7.4. 示例
7.4.1.块注释：
主要用来描述文件，类，方法，算法等。一般用在文档和方法的前面，也可以放在文档的任何地方。以‘/*’开头，‘*/’结尾。例：
……
/*
* 注释
*/
……
7.4.2.行注释：
主要用在方法内部，对代码，变量，流程等进行说明。与块注释格式相似，但是整个注释占据一行。例：
……
/* 注释 */
……
7.4.3.尾随注释：
与行注释功能相似，放在代码的同行，但是要与代码之间有足够的空间，便于分清。例：
int m=4 ; /* 注释 */
如果一个程序块内有多个尾随注释，每个注释的缩进应该保持一致。
7.4.4.行尾注释：
与行注释功能相似，放在每行的最后，或者占据一行。以‘//’开头。
7.4.5.文档注释：
与块注释相似，但是可以被javadoc处理，生成HTML文件。以‘/**’开头，‘*/’结尾。文档注释不能放在方法或程序块内。例：
/**
注释
*/
8.表达式和语句
8.1. 每行应该只有一条语句。
8.2. if-else,if-elseif语句，任何情况下，都应该有“{”，“}”，格
式如下：
if (num1>10 && isOK==true )
{
statement;
}
else if (condition)
{
statements;
}
else
{
statements;
}
8.3. for语句格式如下：
for (initialization; condition; update)
{
statements;
}
如果语句为空：
for (initialization; condition; update) ;
8.4. while语句格式如下：
while (condition)
{
statements;
}
如果语句为空:
while (condition);
8.5. do-while语句格式如下：
do
{
statements;
} while (condition);
8.6. switch语句，每个switch里都应包含default子语句,格式
如下：
switch (condition)
{
case ABC:
statements;
/* falls through */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}
8.7. try-catch语句格式如下：
try
{
statements;
}
catch (ExceptionClass e)
{
statements;
}
finally
{
statements;
}
9.错误处理和异常事件
9.1. 法则
通常的思想是只对错误采用异常处理：逻辑和编程错误，设置错误，被破坏的数据，资源耗尽，等等。
通常的法则是系统在正常状态下以及无重载和硬件失效状态下，不应产生任何异常。
9.2. 方法
异常处理采用日志机制来报告异常（调用系统LOG4J接口统一管理），包括异常发生的时刻。不要使用异常实现来控制程序流程结构。
每一个类或文件都要处理异常或错误。
9.3. 异常封装
Dao层的类中统一封装所有异常为DBException
Service层的类统一获取底层的DBException封装为BusinessException
Action层的类统一捕获Service层的异常并处理。
其它层的异常可以自定义
10.封装、事务
1.非商务公用组件单独封装
2.每一个业务流程单独封装
3.一次方法（组件）的调用应能完成某一项功能或流程，即符合完整性
4.一次方法（组件）的调用符合ACID事务性
5.多次方法（组件）的调用应包含在一个事务中
11.可移植性
1.尽量不要使用已经被标为不赞成使用的类或方法。
2.如果需要换行的话，尽量用 println 来代替在字符串中使用"\n"。
3.用separator()方法代替路径中的“/”或“\”。
4.用pathSeptarator()方法代替路径中的“: ”或“;”。
12.最要注意的问题
1、缩进
缩进以4个空格为单位。预处理语句、全局数据、标题、附加说明、函数说明、标号等均顶格书写。
语句块的"{"、"}"配对对齐，并与其前一行对齐，语句块类的语句缩进建议每个"{"、"}"单独占一行，便于匹对。
2、空格
变量、类、常量数据和函数在其类型，修饰名称之间空格并据情况对齐。
3、对齐
原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在","处或运算符处，换行后最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“{”应与首行对齐。
4、空行
不得存在无规则的空行。程序文件结构各部分之间空两行，各函数实现之间一般空两行，有函数说明或注释，只需空一行或不空。对自己写的函数，加上“//------”做分隔。
5、注释
注释是软件可读性的具体体现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，类似于"处理"、"循环"这样的计算机抽象语言，要精确表达出程序的处理说明。注释必不可少，但也不应过多，不要被动的为写注释而写注释。
6、代码长度
对于每一个函数建议尽可能控制其代码长度为53行左右，超过53行的代码要重新考虑将其拆分为两个或两个以上的函数。函数拆分规则应该一不破坏原有算法为基础，同时拆分出来的部分应该是可以重复利用的。
7、页宽
页宽应该设置为80字符。源代码一般不会超过这个宽度, 并导致无法完整显示。
8、符号风格
对于各种符号的定义，应该使用有实际意义的英文单词或英文单词的缩写，不要使用简单但没有意义的字串，尽可能不使用阿拉伯数字，更切忌使用中文拼音的首字母。
软件项目的编码 一、编码文档 编码阶段的产品是按照代码标准和规范编写的代码，必要的时候进行部署。编码提交的文档包括代码标准规范和源代码。 二、项目案例 项目案例名称：综合信息管理平台 项目案例文档：《综合信息管理平台编码规范及其代码说明》 1、导言 1.1 目的 该文档的目的是描述综合信息管理平台的编码规范和对代码的说明，其主要内容包括编码规范，命名规范，注释规范，语句规范，声明规范，目录设置，代码说明。 本文档的预期读者是开发人员，项目管理人员，质量保证人员。 1.2 范围 该文档定义了本项目的代码编写规范，以及部分代码描述和相关代码的说明。 1.3 术语定义 Class（类）：Java程序中的一个程序单位，可以生成很多实例。 Packages（包）：由很多类组成的工作包。 1.4 引用标准 （1）企业文档格式标准V1.1，北京长江软件有限公司。 （2） 1.5 参考资料 （1） 1.6 版本更新信息 本文档版本更新记录如表X-XXX所示。 表X-XXX 版本更新记录 2、编码书写格式规范 严格要求编码书写格式是为了使程序整齐美观，易于阅读，风格统一，程序员对规范书写的必要性要有明确的认识。建议程序使用Eclipse工具开发，格式规范预先在工具中设置。 2.1 缩进排版 4个空格作为一个缩进排版单位。 2.2 行长度 尽量避免一行的长度超过80个实际字符，用于文档中的例子应该使用更短和行长，长度一般不超过70个字符。 2.3 断行规则 当一个表达式无法容纳在一行内时，可以依据如下一般规则断开： （1）在一个逗号后面断开。
（2）在一个操作符前面断开。 （3）尽量选择较高运算级别处断开，而非较低运算级别处断开。 （4）如果是以上规则导致代码混乱或者使代码都堆挤在右边，那就代之以缩进8个空格。 2.4空行 空行将逻辑相关的代码段分隔开，以提高可读性。下列情况应该总是使用两个空行：（1）一个源文件的两个片段（section）之间。 （2）类声明和接口声明之间。 下列情况应该总是使用一个空行： （1）两个方法之间。 （2）方法内的局部变量和方法的第一条语句之间。 （3）块注释或单行注释之间。 （4）一个方法内的两个逻辑段之间。 3、命名规范 命名规范使程序更易读，从而更易于理解。它们也可以提供一些有关标识符功能的信息，以助于理解代码。 3.1 包（Package） 一个唯一包名的前缀总是全部小写的ASCII字母并且是一个顶级域名，通常是com、edu、gov、mil、net、org，或1981年ISO3166标准所指定的标识国家的英文双字符代码。包名的后续部分根据不同各自内部的命名规范而不尽相同。这类命名规范可能以特定目录名的组成来区分部门（department）、项目（project）、机器（machine）或注册名（login names）。如：com.sun.eng 3.2 类（Class） 类名是一个名词，采用大小写混合的方式，每个单词的首字母大写。尽量使用类名简洁而富于描述性。使用完整单词，避免缩写词（除非该缩写词被更广泛使用，像URL、HTML）。 3.3 接口（Interface） 大小写规则与类名相似。 3.4 方法（Method） 方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。 3.5 变量（Variable） 采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写。变量名不应该以下划线或美元符号开头，尽管这在语法上是允许的。变量名应该易于记忆，且能够指出其用途。尽量避免单个字符的变量名，除非是一次性临时变量。 3.6 实例变量（Instance Variable） 大小写规则和变量名相似，除了前面需要一个下划线。 3.7 常量（Constant） 类常量和ANSI常量的声明，应该全部大写，单词间用下划线隔开。 4、声明规范 程序中定义的数据类型，在计算机中都要为其开辟一定数量的存储单元，为了不造成资源的不必要的浪费，所以按需定义数据的类型，声明包、类以及接口。 4.1 每行声明变量的数量 推荐一行一个声明，因为这样有利于写注释。不要将不同类型变量的声明放在同一行！ 4.2 初始化
项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中，所有项目中的JAVA代码（含JSP，SERVLET，JAVABEAN，EJB）JS代码、HTML代码及数据库设计均应遵守这个规范。同时，也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解，方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。当类包含许多互不相关的方法时，该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下，可以为这些不合群的方法创建一个综合性收容类。 创建类时，应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务，它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。紧密连接的方法
变更履历
目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小
□机密文件■管制文件□一般文件 主题： 项目编码规则 文件编码： 版本：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)
中船重工船业有限公司工程项目编码规则及管理办法 1. 范围 本办法规定公司各种工程编码分类和编码实施规则及其管理办法。 本规则适用于公司内部所有工程项目的编码计划编制、领发料、财务核算、计算机信息处理等。 2. 工程编码类别及其编制规则说明 2.1工程编码类别分为船舶产品工程、非船产品工程、基建工程、自营工程、设备大修、设备维修、设备技改、安全设施及其它工程。 2.2产品工程编码的编制方法 2.2.1 大吨位运输船舶（千吨位以上）工程号的编制方法 2.2.1.1 编码共6 位。前两位为船舶产品载重吨位或承载体积前两位数；第三位为同载重吨位船舶型号，无型号用0 表示，有型号时分为Ⅰ型、Ⅱ型、Ⅲ型等，分别用1、2、3表示，以此类推；第四、五、六位为公司大吨位运输船舶接单顺序号。 2.2.1.2 图示
例如：公司接单第31 艘70000 吨散货船工程编码为：700031 。 公司接单第18 艘33000 吨散货Ⅰ型船工程编码为：331018 。 2.2.2 商务船工程号的编制办法 2.2.2.1 编码共6位。前两位统一名称为SW（商务）；第三、四两位为商务船的长度，五、六两位为商务船接单顺序号。 2.2.2.2 图示 例如：公司接单第1 艘35 米长的商务船，工程号为：SW3501 2.2.3 小吨位（百吨位）运输船工程号的编制办法 2.2. 3.1 编码共6 位。前两位统一名称为YS（运输）；第三、四两位为运输船的吨位前两位，五、六两位为公司小吨位运输船接单顺序号。 2.2. 3.2 图示 例如：公司接单第1 艘载重吨为20 吨的运输船，工程号：YS2001
项目开发规范文档修订历史记录
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) 成员方法尽量私有化。
项目编码管理规定 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.1.1.简介 所有的程序开发手册都包含了各种规则。一些习惯自由程序的人（例如 Java 程序员）可能对这些规则很不适应，但是在多个开发人员共同协作的情况下，这些规则是必需的。这不仅仅是为了开发效率，而且也为了测试和后期维护。 良好的编码习惯有助于标准化程序的结构和编码风格，使源代码对于自己和别人都易读和易懂。在开发周期中越早使用恰当的编码规定，将会最大程度的提高项目的生产率。良好的编码习惯除了代码格式，详细的注释外，还应该包括使用有助于提高程序效率的编码方式。 规的开发有助于提高源码的可读性，可维护性，对于提高项目的整体效率更是不可缺少的（尤其是团队开发）。 1.1. 2.目的 本文是一套面向Java programmer 和Java developer进行开发所应遵循的开发规。按照此规来开发Java程序可带来以下益处： ●代码的编写保持一致性， ●提高代码的可读性和可维护性， ●在团队开发一个项目的情况下，程序员之间可代码共享， ●易于代码的回顾。 1.3.源程序 1.3.1.源程序命名 Java源程序的名字应该是这种形式：ClassOrInterfaceName.java。ClassOrInterfaceName 应该是在Java源程序中定义的 class或者interface的名字（关于classes和interface的命
名规请参考3.2）。源程序的文件名后缀通常为.java。 1.3. 2.供发布的文件 如果文件编译后，需要用打包的形式发布，那么这个包的名字应该是有代表性的（例如应该是这个模块或者这个文件所在单元的名字）。通常包的扩展名有 *.jar(推荐使用)或者 *.zip、*.ear、*.war等。 1.3.3.源文件的组织 一个Java源文件应该包含如下的元素，并按照以下顺序书写： 1)版本信息和声明 2)包的声明 3)引用声明 4)类或者接口的声明 以上元素之间以至少一个空行来分隔。 1.3.3.1.版本信息和声明 每一个源程序应该以一个包含版本信息和声明的块为开始。 例如： /** * application name： sample1 * application describing： this class handels the request of the client * copyright： Copyright ? 2002 金质工程所有 * company： neusoft * time： 2002.02.25 * * author Brunce * version ver 3.1 */
软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied
= stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));
项目编码规范 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.doczj.com/doc/6516282865.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例： getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释（必须加）
项目团队开发规范
修订历史记录
目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12)
3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18)
1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书，描述了项目开发过程中的使用的工具，框架，代码编写规范及注意问题，作为项目团队建设，开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类： ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。
.NET编码规范 .NET编码规范 版本：V1.0
.NET编码规范 目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 1.3参考文档 (1) 2规范概述 (1) 3规范详述 (1) 3.1文件组织 (1) 3.1.1源文件 (1) 3.1.2目录安排 (2) 3.2缩进 (2) 3.2.1分行 (2) 3.2.2空白 (2) 3.3注释 (3) 3.3.1块注释 (3) 3.3.2单行注释 (3) 3.3.3文档注释 (3) 3.4变量声明 (4) 3.4.1每行声明的数量 (4) 3.4.2初始化 (4) 3.5类和接口的声明 (4) 3.6命名约定 (5) 3.6.1大写风格 (5) 3.6.2命名规则 (6) 3.6.3class，struct和namespace命名规则 (6) 3.6.4interface命名规则 (6) 3.6.5enum命名规则 (6) 3.6.6域命名规则 (7) 3.6.7参数命名规则 (7) 3.6.8变量命名规则 (7)
.NET编码规范 3.6.9方法命名规则 (7) 3.6.10属性命名规则 (7) 3.6.11事件命名规则 (8) 3.7代码细节规范 (8)
1 介绍 1.1 目的 本文件的目的是描述用.NET编写代码过程中应遵循的规范，以确保编写出强壮可靠、符合规范的应用程序。虽然这里的代码示例是用C#编写的，但如果使用另外一种编程语言，其中的大多数规则和原理也是适用的。对于.net开发人员，应力求遵守此文档中的规范，代码审查时，此文档将作为重要的参考依据。 1.2 范围 本文件适用于用.NET来实现的软件产品在编码实现过程中应遵循的规范。 1.3 参考文档 [说明本文件的参考文档。] 2 规范概述 本规范为实现过程中用.NET来进行编码时应遵循的规范，主要内容包括：文件组织、缩进、注释、变量声明、类和接口的声明、命名约定及代码细节规范。 在实现过程中的编码实现，代码走查活动中使用到此规范。 3 规范详述 3.1 文件组织 3.1.1 源文件 把每个类都放在单独的文件中，文件名字和类名一致（用.CS作为扩展名）。严禁将多个命名空间/类放在同一个源文件中（https://www.doczj.com/doc/6516282865.html,自动生成的除外）。
管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法， 团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态)，根据监控出现的问题，及时进行处理，改进性能问题，特定情况执行补丁升级。
软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段
这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。
附录 1项目管理编码方案 1.1项目分类 1.1.1编码规则 项目分类采用两层两位字符组合码，1～9加上A～Z（E、I、O及特殊字符除外）。 1.1.2代码表
1.1.3编制说明
项目分类参考了现行的项目分类代码标准。同时在大修、科技项目分类中还参考了《国家电网公司设备大修工作管理办法（试行）》、《国家电网公司技术改造工作管理办法（试行）》相关项目类型的定义及规定。 目前国家电网公司以及各网省公司还保留着部分抽水蓄能电厂以及用于调峰调频、调峰填谷的电厂，为满足这些电力工程的管理需要，在项目分类“基建项目”类中保留了“电源项目”类。 1.2项目编号 1.2.1基建、技改类项目编码规则 1.2.1.1编码规则 项目编号采用4层10位代码结构。 表中： ?N标识该位为数字代码；X标识该位为数字+字母的混合代码。 ?项目类别引用项目类型列表中的2位分类代码。 ?第3、4位代表项目申请单位所属的网省公司，用两位数字标识，直接 引用《国家电网公司直属单位代码》（《国家电网公司直属单位代码》 见人力资源管理编码方案5.1 国家电网公司直属单位代码。）。 ?第5、6位代表项目申请单位，以两位字符标识，由各省自行定义。 ?第7、8、9、10位代表项目编号，以四位字符标识。项目编号流水号允 许实施过程中增加自定义属性信息。 ?项目编号中，当前面代码元素中的一个层次发生变化时，项目编号需重 新开始编号。 1.2.1.2编制说明 基建、技改类项目的项目代码结构包括“项目小类”、“网省公司代码”、“申请单位代码”和“项目编号”四个部分。 与大修、科技、营销类项目编码方案相比，本方案中不包含“立项申请年度”。关于年度问题，编码组讨论了“项目申请年度”、“立项批准年度”等不同的时间点，若采用“项目申请年度”，则从做项目滚动规划到项目申请这之间的时间内，就不能赋予项目相应的编号；若采用“项目申请书编制年度”或“项目开工时间”，也存在同样的问题；采用“立项批准年度”，因有些项目有时会在开
项目编码规范 （一）命名规范 Java包、类的命名应尽量采用完整的英文描述符，一般采用小写英文字母，但类名、接口名以及任何非初始单词的第一个字母要大写，不能用完整英文描述的，应以该英文单词的前四个字母或能代表单词意思的缩写代替。具体如下： （1）尽量使用完整的英文描述符； （2）采用合适于相关领域的术语 （3）采用大小写混合使名字可读 （4）尽量少用缩写，确有需要的，要能表达其意义； （5）避免使用长的名字（小于15个字母） （6）避免使用类似的名字，或者是大小写不同的名字； （7）避免使用下划线（除静态常量等）； 举例如下： 包(packge) 采用完整的英文描述符，应该都是由小写字母组成。对于全局包，将你的internet域名反转并接上包名。如：com.boyi.eim,com.boyi.oa.web 类(Class) 采用完整的英文描述符，所有单词的第一个字母大写。如：User,StuManager 接口(interface) 采用完整的英文描述符说明接口封装,所有单词第一个字母大写。名字后面加上后缀Dao，实体类实现接口加上后缀Impl 类变量：采用完整的英文描述符，第一个字母小写，后所有单词的第一个字母大写。如：userName 参数：同上 获取成员函数:封装字段，被访问时调用get set方法 普通成员函数：采用完整的英文描述符，第一个字母小写，后所有单词的第一个字母大写。 静态常量字段：全部采用大写字母，单词之间用下划线分隔。 循环计数器：通常采用字母I,j,k…………….. 数组：采用完整的英文描述符，第一个字母小写，后所有单词的第一个字母大写 （二）代码注释 良好的注释习惯对于一支程序来说，是其易于解读的关键。也就是说，如果另一个编程人员从未见过这段代码，要在合理的时间内理解代码，需要知道哪些信息。并以此作为注释的依据。因此对于注释来说，需要注意以下几点： （1）注释应该增加代码的清晰度； （2）保持注释的简洁； （3）在写代码之前写注释 （4）注释出为什么做了一些事，而不仅仅是做了什么 使用代码注释的目的: （1）文字说明代码的作用(即为什么要用编写该代码,而不是如何编写); （2）确指出该代码的编写思路和逻辑方法; （3）人们注意到代码中的重要转折点; （4）使代码的阅读者不必在他们的头脑中仿真运行代码的执行方法. 代码注释原则： 1. 用文字说明代码的作用:简单的重复代码做写什么,这样的注释几乎不能给注释增加什么信息.如果你使用好的命名方法来创建直观明 了的代码那么这些类型的注释绝对增加不了什么信息. 2. 如果你想违背好的编程原则,请说明为什么：有的时候你可能需要违背好的编程原则，或者使用了某些不正规的方法，.遇到这种情况 时,请用内部注释来说明你在做什么和为什么要这样做。技巧性特别高的代码段，一定要加详细的注释，不要让其他开发人员花很长时间来研究一个高技巧但不易理解的程序段。 3. 用注释来说明何时可能出错和为什么出错 4. 在编写代码前进行注释：给代码加注释的方法之一是在编写一个方法前首先写上注释.如果你愿意,可以编写完整句子的注释或伪代码.
标识规范 沈阳东大阿尔派软件股份有限公司（版权所有，翻版必究）
文件修改控制
目录 1. 目的 2. 适用范围 3. 术语和缩略语 4. 标识规则 4.1 标识对象 4.2 文档版本控制 4.3 发行版本控制 4.4 软件项标识方式 4.5 不合格品的标识 5. 引用文件 5.1 NW602102《文件编号规定》 6. 质量记录 6.1 NR602101A“文件备份清单”
1．目的 为便于标识、控制和追踪软件开发过程中产生的各种软件项及介质，特制定本文件。 2．适用范围 适用于软件开发过程中所需的各种软件项及介质。 3．术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4．标识规则 4.1 标识对象 标识对象主要包括：技术文档（可行性分析报告、需求分析报告、开发计划、质 量计划、系统设计报告、技术报告、测试计划等）、提交产品（计算机程序、释 放产品等），主要通过介质标识和版本控制以便于存取和查阅。 4.2 文档版本控制 对于计划性文档、技术文档和用户文档，其版本按修改的先后顺序确定。新生成 的文档第一次发行为第一版，修改后第二次发行为第二版，以此类推。 4.3 发行版本控制 最终完成的软件版本用三位符号表示：“s.xy”。各符号位的含义如下： 1）“y”为第二次版本号，表示纠正错误时的版本升级，用一位数字表示：“1~9”，对上一次产品或项目中的缺陷做修正，第二次版本号增加；
2）“x”为第一次版本号，表示增加功能时的版本升级，用一位数字表示：“0~9”。与上一产品或项目相比，功能进行了小量的增加或修正时，第一次 版本号增加，第二次版本号为零，第二版本号为零时可以省略不写； 3）“s”为主版本号，用一位数字表示：“1~9”。对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增加，次版本号 为零，产品或项目概念全新，第一次完成，版本号为1.0。 4.4 软件项标识方式 4.4.1 技术文档标识方式 技术文档的标识体现在相应文件的封面上，由开发人员参照相应文档模板的格式 要求，对技术文档进行标识。 技术文档编号用十五位符号表示：“xxxxxxxxxxxttnn”。各符号位的含义如下：1）“xxxxxxxxxxx”为本次开发的项目编号，共十一位，具体含义见NW602102《文件编号规定》； 2）“tt”为文档类别代号，用两位大写字母表示。“tt”的取值范围如下：FA(Feasibility Analysis)：可行性分析报告 RA(Requirement Analysis)：需求分析报告 DP(Developing Plan)：开发计划 QP(Quality Plan)：质量计划 SD(System Design)：系统设计报告 TR(Technical Report)：技术报告 SR(Summary Report)：项目开发总结报告 本部分未给出代号的文档，其代号由相应的文档编写部门确定。