代码编写规范目的：能够在编码过程中实现规范化，为以后的程序开发中养成良好的行为习惯。
代码编写规范使用范围：J2EE项目开发。
包命名规范：
目的：包的命名规范应当体现出项目资源良好的划分
servlet类所在包命名规范：公司名称.开发组名称.项目名称.web.servlet
例如：net.linkcn.web.servlet
自定义标签类所在包命名规范：公司名称.开发组名称.项目名称.web.tags
例如：net.linkcn.web.tags
过滤器类所在包命名规范：公司名称.开发组名称.项目名称.web.filter
例如：net.linkcn.web.filter
Action类所在包命名规范：公司名称.开发组名称.项目名称.web.struts.action
例如：net.linkcn.web.struts.action
ActionForm类所在包命名规范：公司名称.开发组名称.项目名称.web.struts.form
例如：net.linkcn.web.struts.form
Javabean所在包命名规范：公司名称.开发组名称.项目名称.web.struts.service.impl
例如：net.linkcn.web.service.impl
Javabean实现接口命名规范：公司名称.开发组名称.项目名称.web.service
例如：net.linkcn.web.service
DAO类所在包命名规范：公司名称.开发组名称.项目名称.dao.impl
例如：net.linkcn.dao.impl
DAO类所实现的接口在包中命名规范：公司名称.开发组名称.项目名称.dao
例如：net.linkcn.dao
POJO类与hbm文件所在包命名规范：公司名称.开发组名称.项目名称.dao.hbm
例如：net.linkcn.dao.hbm
全局公共类、接口类所在包命名规范：公司名称.开发组名称.项目名称.global
例如：net.linkcn.global
全局工具类所在包命名规范：公司名称.开发组名称.项目名称.util
例如：net.linkcn.util
类命名规范
基本命名规范：
类、接口命名
命名规范：以大写字母开头，如果有多个单词，每个单词头字母大写
例如：StudentInfo
接口命名
命名规范：以大写字母"I"开头，如果有多个单词，每个单词头字母大写
例如：IStudentInfo
接口实现类命名：
命名规范：将实现的接口名称的首字母"I"去掉，以"Impl作为结尾"，如果有多个单词，每个单词头字母大写。
例如：StudentInfoImpl
J2EE+SSH框架命名规范
servlet类命名：
命名规范：以Servlet单词结尾
例如：LoginServlet
POJO命名：
使用hibernate自动生成的类即可
DAO类命名：
使用hibernate自动生成的类即可
Action类命名：
命名规范：Action的命名以POJO名称来制定，POJO名称Action
例如：
一个POJO名称为Diary，其对应的action为DiaryAction
ActionForm类命名：
命名规范：ActionForm的命名以POJO名称来制定，POJO名称Form
例如：
一个POJO名称为Diary，其对应的actioForm为DiaryForm
业务逻辑接口命名:
命名规范：业务逻辑接口的命名以POJO名称来制定，IPOJO名称Service
例如：
一个POJO名称为Diary，其对应的业务逻辑接口为IDiaryService
业务逻辑实现类命名:
命名规范：业务逻辑接口实现类的命名以POJO名称来制定
例如：
一个POJO名称为Diary，对应的业务逻辑接口实现类名为DiaryServiceImpl
类变量命名：
命名规范：变量名首字母必须小写，如果该变量名有多个单词组成，后面的单 词首字母大写，单词与单词之间不要使用"_"做连接，变量名访问控制必须为私有， 可以对其增加setter与getter方法。
例如：
private int studentAge;
public int getStudentAge(){
return studentAge;
}
public void setStudentAge(int studentAge) {
this.studentAge=studentAge;
}
常量命名：
命名规范：所有字母大写，如果有多个单词组成，单词与单词之间以” _“隔开。而 且该变量必须是公共、静态、final类型
例如：public static final String USER_NAME=”userName“;
方法命名
命名规范：首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母 大写，单词与单词之间不要使用"_"做连接。单词不要使用名词。
例如：public int checkLogin（String name,String pwd）{}
注释规范：注释规范是整个开发规范中最为重要的组成部分，必须严格执行。
类的注释：
作用：注释整个类，简单概述该类作用。
书写规范：类的注释必须写在该类的声明语法之前。在注释中要描述该类的基 本作用，作者，日期，版本，公司名称，版权声明。
格式：
类的声明语法
例如：
public class AdminDAO
变量、常量注释：
作用：简单描述该变量的意义。
书写规范：变量注释必须写在变量定义之前，简单描述其代表的意义。
格式：
例如：
public int age;
方法注释：
作用：对该方法功能简单描述，其参数、返回值意义的注解。
书写规范：方法注释必须写在方法定义之前。该注释包括：方法其功能的简单 描述，方法的参数、返回值类型、返回值意义简单的描述。
格式：
例如：
public booleaneditAdminPassword(int adminId,String oldPassword,
String password) throws UserException,ServiceException;
Jsp页面命名：
命名规范：jsp页面名称要以小写字母开头，如果有多个单词组成，后面的单词以 大写字母开头。名称要体现出该页面的意义，最好能够与模块名称联系在一起。
例如：
login.jsp --登录页面
register.jsp --注册页面
message.jsp --客户留言页面
J2EE项目工程文件夹组织规范：
目的：规范学员web应用程序的资源组织形式，形成良好的文件组织习惯。文件的组织形式应当体现模块的划分。
根据eclipse工具的特征，项目的目录结构为：
src
----存放java文件
WebRoot
|--images --存放web程序所需的公共图片
|--css --存放web程序所需的公共样式表
|--js --存放web程序所需的公共js文件
|--commons --存放web程序所需的公共文件
|--功能模块文件夹(存放与某个功能模块相关的资源)
|--images --存放与该功能模块相关的图片
|--css --存放与该模块相关的样式表文件
|--js --存放与该模块相关的js文件
|--jsp、html页面
|--WEB-INF
|--classes
|--lib
|--tld文件
J2EE项目提交规范
项目完成时要将项目作为一个产品交付用户，良好的项目组织规范可以使用户可以方便的找寻项目中需要的资源，同时也是一个公司专业性的体现。项目提交时，要按照下列文件格式进行提交。
项目主文件夹：
作用：存放项目其他资源文件。
命名规范：时间_班级编号_第X小组。
例如：070706_GS2T18_第四小组。
项目主文件夹下面包括以下文件夹和文件：
|--src：保存.java文件。
|--database：保存数据库的脚本文件或者数据库备份文件。
|--source：保存eclipse工程中WebRoot目录下的所有文件。
|--depend：保存编译该程序必须依赖的其他jar文件。
|--javadoc：保存所有类生成的javadoc api文档。
|--war：保存程序的归档文件
|--xx.war：已经打包好的工程文件，可以直接运行。
|--project：保存开发项目原工程代码及文件。
|--产品说明书.doc：图文方式展现该产品使用方法。
|--build.xml：ant脚本，用于生成运行的war文件。
|--项目解说.ppt：进行项目讲解的ppt（ppt仅供在校模拟项目使用，不用于其他商业用途）
注：一个完整的项目中，数据库必须有一定量的有效的测试数据来支持该程序的运行
包的命名
Java包的名字都是由小写单词组成。但是由于Java面向对象编程的特性，每一名Java程序员都可以编写属于自己的Java包，为了保障每个 Java包命名的唯一性，在最新的Java编程规范中，要求程序员在自己定义的包的名称之前加上唯一的前缀。由于互联网上的域名称是不会重复的，所以程序 员一般采用自己在互联网上的域名称作为自己程序包的唯一前缀。
例如： net.frontfree.javagroup
类的命名
类的名字必须由大写字母开头而单词中的其他字母均为小写；如果类名称由多个单词组成，则每个单词的首字母均应为大写例如TestPage；如果类名 称中包含单词缩写，则这个所写词的每个字母均应大写，如：XMLExample,还有一点命名技巧就是由于类是设计用来代表对象的，所以在命名类时应尽量 选择名词。
例如： Circle
方法的命名
方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。
例如： sendMessge
常量的命名
常量的名字应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词。
例如： MAX_VALUE
参数的命名
参数的命名规范和方法的命名规范相同，而且为了避免阅读程序时造成迷惑，请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。
Javadoc注释
Java除了可以采用我们常见的注释方式之外，Java语言规范还定义了一种特殊的注释，也就是我们所说的Javadoc注释，它是用来记录我们代 码中的API的。Javadoc注释是一种多行注释，以结束，注释可以包含一些HTML标记符和专门的关键词。使用Javadoc 注释的好处是编写的注释可以被自动转为在线文档，省去了单独编写程序文档的麻烦。
例如：
在每个程序的最开始部分，一般都用Javadoc注释对程序的总体描述以及版权信息，之后在主程序中可以为每个类、接口、方法、字段添加 Javadoc注释，每个注释的开头部分先用一句话概括该类、接口、方法、字段所完成的功能，这句话应单独占据一行以突出其概括作用，在这句话后面可以跟 随更加详细的描述段落。在描述性段落之后还可以跟随一些以Javadoc注释标签开头的特殊段落，例如上面例子中的@auther和@version，这 些段落将在生成文档中以特定方式显示。
变量和常量命名
变量命名的方法采用匈牙利命名法，基本结构为scope_typeVariableName，它使用3字符前缀来表示数据类型，3个字符的前缀必须 小写，前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。例如， 定义一个整形变量，用来记录文档数量：intDocCount，其中int表明数据类型，后面为表意的英文名，每个单词首字母大写。这样，在一个变量名就 可以反映出变量类型和变量所存储的值的意义两方面内容，这使得代码语句可读性强、更加容易理解。byte、int、char、long、float、 double、boolean和short。
变量类型和首字母对照关系如下表：
数据类型/对象类型 / 变量前缀 / 备注
byte bye
char chr
float flt
boolean bln 做布尔变量时，使用bln
Integer/int int
String str
Single sng
short sht
Long/long lng
Double/double dbl
Currency cur
Variant bln astr obj vnt 做布尔变量用时，用bln，做字符串数组用时，用astr，做为对象使用时，用obj，不确定时，用vnt。
对于数组，在数据类型的前缀前再增加一个a，例如字符串数组为astr。对于在多个函数内都要使用的全局变量，在前面再增加“g_”。例如一个全局的字符串变量：g_strUserInfo。
在变量命名时要注意以下几点：
· 选择有意义的名字，注意每个单词首字母要大写。
· 在一段函数中不使用同一个变量表示前后意义不同的两个数值。
· i、j、k等只作为小型循环的循环索引变量。
· 避免用Flag来命名状态变量。
· 用Is来命名逻辑变量，如：blnFileIsFound。通过这种给布尔变量肯定形式的命名方式，使得其它开发人员能够更为清楚
的理解布尔变量所代表的意义。
· 如果需要的话，在变量最后附加计算限定词，如：curSalesSum。
· 命名不相包含，curSales和curSalesSum。
· Static Final 变量的名字应该都大写，并且指出完整含义。
· 如果需要对变量名进行缩写时，一定要注意整个代码中缩写规则的一致性。例如，如果在代码的某些区域中使用intCnt，而在另一些区域中又使用intCount，就会给代码增加不必要的复杂性。建议变量名中尽量不要出现缩写。
· 通过在结尾处放置一个量词，就可创建更加统一的变量，它们更容易理解，也更容易搜索。例如，请使用 strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。常 用的量词后缀有：First（一组变量中的第一个）、Last（一组变量中的最后一个）、Next（一组变量中的下一个变量）、Prev（一组变量中的上 一个）、Cur（一组变量中的当前变量）。
· 为每个变量选择最佳的数据类型，这样即能减少对内存的需求量，加快代码的执行速度，又会降低出错的可能性。用于变量的数据类型可能会影响该变量进行计算所产生的结果。在这种情况下，编译器不会产生运行期错误，它只是迫使该值符合数据类型的要求。这类问题极难查找。
· 尽量缩小变量的作用域。如果变量的作用域大于它应有的范围，变量可继续存在，并且在不再需要该变量后的很长时间内仍然占用资源。它们的主要问题是，任何类 中的任何方法都能对它们进行修改，并且很难跟踪究竟是何处进行修改的。占用资源是作用域涉及的一个重要问题。对变量来说，尽量缩小作用域将会对应用程序的 可靠性产生巨大的影响。
关于常量的命名方法，在JAVA代码中，无论什么时候，均提倡应用常量取代数字、固定字符串。也就是说，程序中除0，1以外，尽量不应该出现其他数 字。常量可以集中在程序开始部分定义或者更宽的作用域内，名字应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下 划线“_”来分割这些单词如：NUM_DAYS_IN_WEEK、MAX_VALUE。
转载自：
http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html 本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：
第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。
建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例
第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例
第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例
第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例
第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。
第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。
经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。
http://hi.baidu.com/parryblog/blog/category/%CF%B5%CD%B3%B7%D6%CE%F6
http://hi.baidu.com/parryblog/blog/category/%D0%E8%C7%F3%B7%D6%CE%F6