项目编码规范.docx
《项目编码规范.docx》由会员分享，可在线阅读，更多相关《项目编码规范.docx（15页珍藏版）》请在冰豆网上搜索。
项目编码规范
项目代码编程规范
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.幸免利用等那些在前就有的集合类因为"Unlikethenewcollectionimplementations,Vectorissynchronized."，所以使用类在性能上会有所减低。
5.尽可能利用接口而不是一个具体的类比方如下需求，给定一个SQL语句，返回一个对象的列表，实现中用实现，于是定义方法为：
publicgetObjectItems（Stringsql）上面的方法存在一个问题，当getObjectItems内改用Vector或LinkedList实现，外部类必须做相应更改。
一个更好的方法是定义返回值为更合适：
publicgetObjectItems（Stringsql）这样即使更改实现，外部类也不必做相应更改。
6.幸免利用索引来挪用数据库中间层组件返回的结果集如：
for（inti=1;i<=（）;i++）
{Stringfield1=（i,0）.toString（）;……}而应用字段名来存取结果集：
for（inti=1;i<=（）;i++）
{Stringfield1=（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.举例
ClassHello;
ClassHelloWorld;
InterfaceApple;
ClassAppleImplimplementsApple;
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.举例
StringfileName;
int[]students;
inti;
intn;
booleanisPass;
3.6.常量
3.6.1.约定
所有常量名均全数大写，单词间以‘_’隔开。
利用英语单词，不要利用汉语拼音
特殊情形下能够利用全拼，可是请注释说明
3.6.2.举例
intI_MAX_NUM;
3.7.jsp,html,xml等文件
3.7.1.约定
利用英语单词，不要利用汉语拼音
首单词小写，其它单词首字母应该大写
幸免利用单词的缩写，除非它的缩写已经广为人知，如HTTP
3.7.2.举例
注册，新增
查询页面视图
保护页面视图
按日期查询页面视图
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.尾随注释：
与行注释功能相似，放在代码的同行，可是要与代码之间有足够的空间，便于分清。
例：
intm=4;/*注释*/
若是一个程序块内有多个尾随注释，每一个注释的缩进应该维持一致。
7.4.4.行尾注释：
与行注释功能相似，放在每行的最后，或占据一行。
以‘商务公用组件单独封装
2.每一个业务流程单独封装
3.一次方式（组件）的挪用应能完成某一项功能或流程，即符合完整性
4.一次方式（组件）的挪用符合ACID事务性
5.多次方式（组件）的挪用应包括在一个事务中
8.可移植性
1.尽可能不要利用已经被标为不同意利用的类或方式。
2.若是需要换行的话，尽可能用println来代替在字符串中利用"\n"。
3.用separator（）方式代替路径中的“/”或“\”。
4.用pathSeptarator（）方式代替路径中的“:
”或“;”。
9.最要注意的问题
一、缩进
缩进以4个空格为单位。
预处置语句、全局数据、题目、附加说明、函数说明、标号等均顶格书写。
语句块的"{"、"}"配对对齐，并与其前一行对齐，语句块类的语句缩进建议每一个"{"、"}"单独占一行，便于匹对。
二、空格
变量、类、常量数据和函数在其类型，修饰名称之间空格并据情形对齐。
3、对齐
原则上关系紧密的行应付齐，对齐包括类型、修饰、名称、参数等各部份对齐。
另每一行的长度不该超过屏幕太多，必要时适当换行，换行时尽可能在","处或运算符处，换行后最好以运算符打头，而且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“{”应与首行对齐。
4、空行
不得存在无规则的空行。
程序文件结构各部份之间空两行，各函数实现之间一样空两行，有函数说明或注释，只需空一行或不空。
对自己写
升级会员 