JAVA软件开发规范
一、绪论
1.1概述
随着公司上ERP项目，为统一开发技术规范，缩短开发周期，进一步提高项目质量，降低后期维护难度，迫切需要一个更完善、专业、有效的开发规范。
本规范的目的是使本科室JAVA开发能以统一、标准的、规范的方式设计和编码。通过建立开发规范，使每个开发人员养成良好的开发风格和习惯；提高程序的可靠性、可读性、可维护性和一致性等，提高程序员的开发水平，增进团队间的交流，并保证软件产品的质量。
1.2适用范围
本规范适用于本公司所有JAVA软件项目、产品等的设计、开发以及维护等。所有JAVA软件开发人员在整个软件开发过程中必须遵循此规范。
二、总体框架
2.1框架概述
本公司JAVA开发的软件产品多为B/S结构，涉及多个层面的开发，为便于逻辑分离及项目分工，开发的软件产品应当符合MVC设计模式，基础框架使用SSH（spring+hibernate+struts2）MVC基础框架。
2.2框架规范
旧框架中Servlet层应当仅负责宏观层面的业务逻辑，不进行具体的数据访问，新框架中Action组件负责事务同旧框架中的Servlet层组件。Model由开发人员自己实现。hibernate是将原来的 DAO部分，就是数据库部分，进行数据持久化，可以理解为数据库的接口和对数据库的操作之一。spring是管理容器的角色，降低耦合度，方便管理。
2.2.1 Hibernate DAO规范
DAO为数据访问组件，用于访问持久性数据，例如为关系型数据库。本规范要求DAO对象必须直接或间接继承数据访问组件的基础类
com.yonggang.framework.hibernate.HibernateDAOSupport ,该基类已经实现了hibernate通用的查询，更新，插入，删除，分页查询等操作，业务类继承该类后即可使用HibernateDAOSupport提供的hibernate数据库操作方法。
DAO处理完正常逻辑后设置本次处理后用于界面提示的消息。禁止DAO类依赖于request等Web对象，便于DAO类可以脱离于Web应用。
2.2.2业务处理类BO规范
在BaseBO当中，提供了业务开发常用方法，比如采用Hibernate方式的普通查询、分页查询、对象的保存与更新，还提供了Jdbc方式的普通查询、分页查询、数据更新等。开发当中可以创建一类业务处理的“BaseBO”，比如“WorkflowBO”，该BO扩展自“com.yonggang.framework.base.BaseBO”，项目当中工作流业务模块皆要扩展这个新创建出来的WorkflowBO。具体的业务模块当中就可以扩展这个WorkflowBO，编写相关的业务方法。
其中的业务方法如果需要事务包裹，要以update、delete、save、process、execute 开头，并且配置将该BO配置到Spring当中时，Bean的命名要以BO结尾。
编写好业务类之后，我们需要将其配置到spring的配置文件当中，通常情况下，我们建议您在您的模块的src目录下创建一个configs目录，在其下放置您的spring配置文件，这样，因为是分模块配置对应的spring配置文件，所以即使在多人开发的场景下也不会产生配置文件编辑的冲突问题。下面表格当中向我们展示了TestBO在Spring配置文件中的配置情形。
TestBO配置示例
从上面的配置当中可以看到，我们建议您在Spring当中配置您的BO的时候，bean的ID命名方式采用模块名+“.”+类名（首字母小写）的方式，如上面的bean的名字为“modulea.testBO”，这里的modulea是模块名称，testBO是类名（首字母小写）。通过这种命名方式，我们从Bean名称上就可以看出Bean的作用，同时这种命名方式还可以防止重名。
2.2.3Action规范
新框架以Action层组件代替Servlet层组件。此处，Action组件将主要负责业务逻辑开发、消息设置、页面导航设置，不再需要管理资源释放(如数据库连接的释放)。
Action类都必须直接或间接继承类com.opensymphony.xwork2.ActionSupprot 与DAO的理由一致，每一套应用也应当定义自己的Action入口，此处假定其名称为AppAction。
2.2.4角色权限用户验证规范
使用spring security3作为本框架的安全验证，使用SpringSecurity可以与spring无缝集成，扩展性很强。下面简单说明下spring security 的业务流程：
1）容器启动(MySecurityMetadataSource：loadResourceDefine加载系统资源与权限列表)
2）用户发出请求
3）过滤器拦截(MySecurityFilter:doFilter)
4）取得请求资源所需权限(MySecurityMetadataSource:getAttributes)
5）匹配用户拥有权限和请求权限(MyAccessDecisionManager:decide)，如果用户没有相应的权限，执行第6步，否则执行第7步。
6）登录
7）验证并授权(UserDetailServiceImpl:loadUserByUsername)
8）重复4,5。
该框架中已经实现了基于SpringSecurity的角色权限验证。
2.2.5工作流引擎规范
项目中如果需要使用到工作流引擎，则使用JBPM作为工作流引擎，需要在项目目录下WEB-INF\config\spring\applicationContext.xml中如图：
配置示例
把注释释放掉即可。框架
JBPM4做了封装和扩展，使用工作流时，写工作流业务类需要继承工作流程业务基类WorkflowBO后通过getWorkflowService()方法获取工作流操作方法实现工作流引擎操作。定义完业务类需要将其配置到spring的配置文件当中，如图：
配置示例
三、Java开发规范
本部分着重B/S结构中Server端Java代码的规范，同样适用于基础库开发。公用功能的程序由公司基础库提供。基础库应当在实际项目中提炼，采用共同讨论，专人维护的方式进行。基础库生成JavaDOC文档，开发人员应当仔细阅读，利于应用开发。
3.1风格规范
3.1.1风格概述
实际的开发中，由于项目期限等原因，尽管已经有初步的开发规范，但在项目后期常常失控，为了赶进度，开发人员逐渐养成了一些不良的习惯。命名随意,汉语拼音英文混合、注释不清晰、导入不使用的类、定义不使用的变量、方法存在不需要的参数、方法命名与方法实现功能不一致、程序缩进不一致等。这些都是需要规范的地方。
好的程序书写规范比随意的书写规范更清晰、错误更少、更易修改。所以，一开始就要注意使用好的编写风格。好的程序设计风格就如同好的文章，不仅要求语句顺畅，而且段落分明，结构紧凑。不仅排版要清晰，标点符号正确使用，而且重点要突出，中心明确。
让我们从这些基本的编程技术基础上入手，改正以前的不良习惯，逐步提高应用交付的质量。
3.1.2类(包)导入规范
在import需要用到的类时，尽量少用import *；而应当具体指明需要导入的类，利于代码阅读，知道用到了具体的什么类。导入需要用到的类应当按照一定的顺序导入，不能随便写，此处规定，导入顺序如下，且前后类别之间以空行隔开：
Java标准包类
Java扩展包类
第三方组件包类
自行开发基础库包类
业务系统自身基础包类
3.1.3缩进规范
源码缩进不仅仅使程序更美观，而且也使程序结构更清晰、易读。采用统一缩进4个空格方式。在类的定义、方法体的开始以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。
3.1.4表达式和语句规范
表达示和语句是程序中使用最多的基本语法，也是构成程序逻辑的基本要素，它们的不合理使用很大地影响了程序的清晰性、简洁性。
3.1.5括号规范
在表达示中，因为算术运算符，关系运算符和逻辑运算符的优先级别一般很难记清，因此规定采用括号“（）”显式划分计算的优先级，排除二义性。
在条件判断中，无论执行语有几条，都应当以大扩号“{}”括起来。
3.1.6空格规范
关键词和操作符之间加空格；
方法名之后不要留空格，紧跟左括号“（”，以与关键字区别；
方法中参数之间夹空格；
赋值操作符、比较操作符、算术操作符、逻辑操作符、位与操作符，如“=”、“+=”“>=”、“<=”、“+”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格；
一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格；
对于表达式比较长的for语句和if语句，为了紧凑起见可以适当地去掉一些空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))。
3.1.7空行规范
包命名的行和后续导入的类(包)之间加一个空行；
按3.1.2规范导入的类(包)之间加空行；
在导入类和类注释之间加空行；
方法和方法之间加空行；
相对独立的程序块与块之间加空行；
较长的语句、表达式等要分成多行书写；
划分出的新行要进行适当缩进，使排版整齐，语句可读。
长表达式要在低优先级操作符处划分新行，操作符放在新行之首；
循环、判断等语句中若有较长的表达式或语句，则要进行适当划分；
方法参数较长，进行适当的划分；
不允许把多个短语句写在一行中，即一行只写一条语句；
方法或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
程序的分界符“{”和“}”应独占一行并且位于同一列，同时与引用它们的语句左对齐；
3.1.8注释规范
为便于维护，对程序应当给出适当的注释。
类(接口)注释
对类和接口应当加以注释，对该类作一个简单功能描述，同时还可以标注其他内容：如公司名称，开始编写日期等，但作者必须标注上，方便在出现问题时由原作者负责解释。
方法注释
应当对方法进行注释。注释必须含“功能”描述，参数描述，返回值描述。如果参数较为复杂，或者怕遗忘，则详细说明每个参数的作用、取值范围及相互间的关系。
3.2模块划分
合理的模块划分能提高项目的效率。在一个项目开始之前，应当进行合理的模块划分。划分之后任一模块的业务代码应当仅依赖于下述包(或类)： Java标准包
Java扩展包
第三方组件包
业务系统基础包
除此之外，不应该再导入其他类(包)，如有导入，则说明模块划分可能不够合理。设计人员在设计之初应当对此进行全局考虑。
3.3包存放规范
尽管Java支持未命名包，但为让程序显得美观、清晰直观，程序应当放到相应的包下。开发的程序应当放到com.yonggang包或其子目录下。
此处规定，禁止写未命名包的程序，希望大家遵守。
3.4命名规范
命名采用英文命名，禁止采用中文汉语拼音缩写命名，命名采用大小写混合，提高可读性。命名应当能顾名思义，能够正确表达出想要表达的意思。
3.4.1包命名规范
包表示一对类的共同含义，可以对应应用开发的模块，必须以名词(或动名词)命名，必须全部采取小写字母形式，并具备规定的层次。
如com.yonggang.ygoa.report包表示出现在该包内的类都是为报表服务的。
3.4.2类(接口) 命名规范
类和接口表示一类对象，必须以名词命名。类名的第一个字母必须大写，类名如由多个单词(或缩写)构成，则每个单词(缩写)的头一个字母必须大写。如消息管理器命名为MessageManager。
为统一起见，对我司的框架中出现的四种类做出进一步规定，如下：
DAO类
DAO类必须以“DAO”三个大写字母结尾，如AmsAssetsCheckHeaderDAO；
Servlet类
Servlet类必须以“Servlet”结尾，如AmsAssetsCheckHeader Servlet。
类(接口)名和表名的对应关系为：表名第一个字母大写不变，后续字母变为小写，直到遇到下划线“_”，下划线“_”不出现在类名中，下划线“_”紧跟的字母保持大写不变，后续字母又变为小写，以此类推。
对于不需要单独维护或查询表，不需要写对应的Servlet类，但其他三类应当提供，由其他的DAO类调用。
3.4.3方法命名规范
方法表示一次操作，因此必须以动词形式命名。方法名第一个字母采取小写形式，其余字母同类(接口)的命名规则。
3.5方法编写规范
3.5.1基本原则
方法是Java的基本功能单元，一个方法应当只完成一项功能。对于公用接口外的方法，应当尽可能缩小其可见性，避免用一个类实例去访问其静态变量和方法。当一个方法被调用之后，方法所在类应当反馈出本次调用是成功还是失败，如果被调用方法不能反馈结果，则同一类中其他方法应当提供。
3.5.2参数规范
禁止方法提供超过四个的参数。如果确实需要更多参数，则用参数建立新的值对象，以此对象做参数。参数类型和返回值尽量接口化，以屏蔽具体的实现细节，提高程序的可扩展性。在方法的入口处对参数进行有效性检查。很多程序错误是由非法参数引起的。良好的编程典范规定：当编写一个方法时，必须验证所有传递进来的参数，如果任何一个参数不合乎要求，就应当明确地引发一个异常。boolean参数不应当检查。
3.5.3出口规范
对于有返回值的方法，禁止提供多个出口，而只能提供一个出口。
3.5.4注意事项
方法的规模尽量限制在200行以内。超过200行则多半存在可以独立的逻辑单元，则可以将其抽取出去另写方法；
一个方法仅完成一件功能；
为简单功能编写方法；
方法的功能应该是可预测的，也就是只要输入数据相同就应产生同样的输出；
尽量不要编写依赖于其他方法内部实现的方法；
避免设计多参数方法，不使用的参数从接口中去掉；参数多时将之作为新对象的字段，以对象形式传入；
用注释详细说明每个参数的作用、取值范围及相互间的关系；
检查所有参数输入的有效性；
检查所有非参数输入的有效性，如数据文件、公共变量等。
方法名应准确描述方法的功能；
方法的返回值要清楚、明了，让使用者不容易忽视错误情况。
减少方法本身或方法间的递归调用；
3.6语句选择规范
3.6.1分支语句
分支语句有if，switch两种。if语句多用于分支较少的情况，switch语句正好相反。当分支较多时，采用if语句显得冗长，建议采用switch语句。
3.6.2循环语句
Java循环语句中，for语句使用频率最高，while语句其次，do语句很少用，可根据自己熟悉程度选用，但应当考虑效率问题。在循坏次数不太多时，三种语句循环效率无明显差别；当循环次数较大时，效率最高的是do循坏，其次是for 循坏，最后是while循坏。
多重循环效率问题
在多重循环中，如果有可能，应当将最长的循环放在最内层，最短的循环放在最外层，以减少CPU跨切循环层的次数。
循环内逻辑判断问题
如果循环体内存在逻辑判断，并且循环次数很大，宜将逻辑判断移到循环体外面。
特殊规定
如无必要，不应该在for 循环体内修改循环变量，防止for 循环失去控制。
3.7异常处理与资源回收
3.7.1异常处理
异常处理的基本思想是只对错误进行处理，如数据库操作、文件操作中的错误以及有限性资源耗尽等。
捕捉异常是为了处理它，不要捕捉后却不做任何处理。如果不想处理，则应当申明方法抛出相应异常，由调用者处理。禁止使用一个catch语句处理多个异常，应当分别捕捉并处理。
一个方法申明抛出的异常个数应当最小化，最好只抛出一个异常。如果确实要捕捉处理多个异常，可记录下非申明异常的错误信息，并将之转化为申明异常抛出。
捉到的异常应当记录下来，记录由基础库提供的日志工具完成。禁止将异常直接输出到控制台。
经常发生的可预计事件不进行异常捕捉及处理，方法已申明抛出的异常不需捕捉。禁止使用异常实现逻辑控制。
应当在本地进行安全性检查，而不是让程序的调用者完成。
3.7.2资源回收
有限性资源使用完毕后，应当立即释放。如数据库连接，I/O操作等。无论程序是否发生异常，资源都应当得到回收。
回收资源的代码应当位于finally子句内，以保证资源得到释放，禁止与正常的业务处理代码混在一块。
如果类中有限性资源是全局性共享资源，则类还应当提供finalize方法，由JVM 在资源回收的时候调用finalize方法，做最后释放。
3.8性能与安全
3.8.1基本原则
程序在满足功能的情况下，应当尽量提高运行性能。程序的运行性能很大程度上由SQL语句决定，SQL语句的在编写时在满足功能要求前提下需要提高SQL 运行效率。
3.8.2减少重复计算
如果一个计算或查询多次出现，那么就只在一个地方实现，并记录结果。这样会避免无谓的重复计算与查询工作，计算越复杂性能牺牲就越大。
3.8.3可变字符串
处理可变字符串时，尽量使用StringBuffer类而非String类。由StringBuffer 对象完成大部分工作，完成后将之转换为需要的String对象。在1.5及以上的JDK 版本中可以选中使用StringBuilder类，其效率比String更高。
3.8.4集合实现
禁止使用Vector和HashTable等旧集合实现，在新的系统设计中应当分别使用ArrayList和HashMap代替。
数组的性能比Vector和ArrayList高，如果元素个数不变，尽量使用数组。
在使用集合类时，变量的定义以及参数的接收应当使用接口，而非具体实现类。
3.8.5对象创建与释放
禁止在循环中频繁构建和释放对象；不再使用的对象应当及时销毁；如无必要，不要序列化对象。对于频繁使用的对象，可将其缓存起来，下次使用时直接从缓存中获取对象。
3.8.6代码同步
在不需要同步操作时禁止使用同步操作；尽量少用同步方法，避免使用太多的synchronized 关键字。
确需使用同步时，尽量将同步代码的范围最小化。
四、WEB开发规范
本部分着重B/S系统开发中的JSP编写规范。
4.1目录规范
4.1.1一般原则
Web程序要按照一定的目录存放。建立积累Web基础库，目前主要指Javascript和CSS，今后随发展积累进一步提取，以促进开发应用的成熟度。从Web应当用的根目录算起，应当用目录不应超过三层。目录名称建议也采用Java 命名规范。
4.1.2根目录
J2EE平台上，包含“/WEB-INF”目录的目录称作根目录。
应用本身的基础性文件必须位于Web根目录下。
与具体业务相关的页面不能直接位于根目录下，必须位于根目录下相应模块的子目录下。
4.1.3公用资源目录
Web基础库作为公用资源，供每套应用使用。在Web根目录下建立/styles /js目录和/styles/css目录，分别存放Javascript函数库和样式表文件。
除此之外，图片文件也作公用资源看待。在根目录下建立/images目录，其下直接存放整套应用需要使用的图片资源文件。在/images目录下以模块名建立子目录，用于存放每个模块需要用到的图片文件。其他目录不应当再存在图片文件。
建立public目录，用于存放其他公用性强的文件，包含各业务模块下公用性强的文件。
4.1.4业务模块目录
根目录下以业务模块名称建立子目录，用于存放各自的文件。如一个模块过大或有部分独立功能，可在其下再建立一层子目录。
4.1.5文件引用规范
由于常采用servlet的forward的形式进行请求的转发，文件之间以“相对目录”的形式引用常常出错。为此规定，在Web应用中，任何文件的应用都应当采用绝对目录(此处决对目录指相对于Web根目录而言)。
我司开发的应用，目前文件间的引用都是采用的绝对目录。
但目前我司开发的应用还存在一个缺陷，当Web应用配置的虚拟目录不为空时，文件间的应用会出错，即找不到引用的资源。此处规定，在今后的Web 开发中，在根目录“/”前加上虚拟目录，在JSP中以request.getContextPath()获取。示例如下：
%>/images/news/Styleb1_1.gif”></p><p>4.1.6配置文件目录</p><p>配置文件可以提高灵活性，以适应相应的变化。位于/WEB-INF/目录下的web.xml是符合J2EE规范的标准配置文件，任何符合J2EE规范的应用服务器必须能正确解析该文件。其他配置文件也应当由该配置文件引导加载。</p><p>最好的应用是在web.xml文件中只指定一个加载入口，而不应当加入其他的具体配置。</p><p>提供的配置文件位于/WEB-INF/config目录下。</p><!--/p13--><!--p14--><!--/p14--><!--p15--><p>4.2HTML规范</p><p>通常由于浏览器的容错功能太强，即使编写不规范的页面浏览器也能解析。但我们写的程序不仅需要浏览器能识别，更大程度上需要人能识别，符合一定的规范代码更以维护。为此规定以下相关事项。</p><p>4.2.1页面规范</p><p>所有标记均为小写；</p><p>标记属性均为小写，属性值必须以双引号括起来；</p><p>编辑页面的文本输入框必须指定“maxlength”属性值，以免插入数据库中长度越界；</p><p>HTML代码必须以<HTML>开头，</HTML>结尾；</p><p>所有的Script及其外部引用、CSS 及其外部引用均放入<HEAD></HEAD>中；</p><p><HEAD></HEAD>之间应当设置页面所使用的语言，如</p><p><META http-equiv=)
所有HTML页面必须在
或“未命名”标题的页面；
从菜单栏目链接打开的页面标题必须与菜单栏目描述一致；
4.2.2元素name命名规范
表单域元素必须命名，且必须与DTO字段名一致。
4.2.3元素id命名规范
尽管元素的id属性不是后台servlet所必需的，但为了页面Javascript操作的方便，id属性也应当命名，名称必须以双引号引起来。
4.3JSP规范
4.3.1JSP页面规范
JSP页面必须指定页面的编码，且放在第一行的位置，编码全部采用“UTF-8”；
JSP页面引用类的导入规范同3.1.2部分的Java导入规范；
禁止在页面导入Java.sql包中的任何类；
JSP页面不需要对会话进行判断，由基础库提供的filter统一完成；
JSP页面不需要写缓存清除代码，由基础库提供的filter统一完成；
禁止JSP页面直接提交给JSP页面，必须提交给控制器Servlet转发处理；
4.3.2JSP编码规范
禁止JSP出现过多Java代码；
禁止在JSP页面出现数据库连接Connection
禁止在JSP页面写公共方法；
?JSP页面中的Java脚本代码必须位于“<%”和“%>”之间，且“<%”
和“%>”必须各自占一行，“<%”和“%>”必须位于一行的开头；示
JSP页面连续的Java代码不能之间有多余的“<%”和“%>”jsp
JSP页面尽量使用标签
4.3.3列表记录页面规范
4.3.4数据有效性验证
数据编辑页面(含新增，修改，删除数据)提交的数据，必须进行有效性验证。有效性验证分为两类：字面格式的验证和业务逻辑的验证。除了必须有后台数据参与才能完成验证的以外，字面格式的验证以及简单的业务逻辑验证，应当在JSP 页面完成，减轻服务器负载。
有效性验证由公司的Javascript基础库完成，不能完成的，如果该验证功能是通用性需求，则扩充基础库功能，否则由该模块开发人员自行开发javascript 方法完成。
4.4安全验证
Web应当中，除个别jsp页面或servlet外，其它Web页面或servlet都应当是受保护的资源，对Web页面的访问必须由安全验证程序进行验证。验证通过后方可访问。
安全验证包含会话有效性验证和权限验证。
禁止会话验证代码散布在JSP页面或Servlet中，会话验证程序由基础库统一提供。
权限验证程序由基础库统一提供。如个别模块有特殊权限需求，则相应当模块的应当用程序自行验证相应权限。
五、附录
Java开发规范
目录 第1章序言 (4) 第2章java一般性研发规范 (5) 2.1 代码格式 (5) 2.1.1包、类、方法的命名规范: (5) 2.1.2方法的命名应注意避免与java中具有特殊意义的名称例如equals， hashCode，clone，finalizer等冲突 (7) 2.1.3Java bean中取得boolean类型的属性值必须使用is****形式命名 (9) 2.1.4if,else,while,for等必须使用{} (9) 2.1.5类必须包含在包里，禁止出现无包的类 (10) 2.1.6类和方法必须拥有注释，注释量占总体代码25%以上，类头部，以及方法 头部的注释应符合javadoc标准。 (11) 2.2 基本语法 (12) 2.2.1不能随意捕捉异常，原则上谁捕捉谁处理 (12) 2.2.2if，while，try，finally，switch ，synchronized ，static instantiation 里面应有相应的逻辑处理，不能为空。 (13) 2.2.3在处理循环中，不能在程序中人为的改变步长。 (14) 2.2.4将简单类型int，short，float，double等转化成字符串时，需使用其对 应类的toString方法。 (14) 2.2.5javaBean中hashCode，以及equals方法必须同时override。 (15) 2.2.6懒式方式创建对象：不能采用双检查惯用法 (18) 2.2.7不能在finally中返回值。 (19) 2.2.8Boolean实例化时，应用使用Boolean.valueOf，Boolean.TRUE， Boolean.FALSE。 (19) 2.2.9Integer,Byte,Short,Long等实例化时，应用使用valueOf (20) 2.2.10对于多个if语句嵌套的情况下能够整合尽量整合。 (20) 2.2.11override function，不能只有super.function语句，否则视为无效代码 21 2.2.12Collection.toArray的注意事项。 (21) 2.2.13对于BigDecimal方法，应避免使用float值，double值进行创建，应使 用字符串形式创建。 (22) 2.2.14String,BigDecimal,BigInteger等值类型调用replace，add等方法的注 意事项。 (23) 2.2.15需要注意的引起NullException的语句。 (23) 2.2.16ResultSet使用next时，需要判断是否具有记录再进行一下步操作。 25 2.2.17字符串使用相应的规则。 (25) 2.2.18禁止直接调用 System.gc(),System.getRuntime().gc(),System.runFinalization()。 (27) 2.2.19finalize相应的规则。 (27) 2.2.20禁止在代码中使用System.out,ex.printStackTrace打印日志。 (28) 2.2.21系统资源释放（谁创建的，谁关闭） (29) 2.2.22使用Clone时相应的规则。 (32) 2.2.23java Bean类必须实现Serialize接口。 (33)
软件系统JAVA 编码规范 版本V1.0
文档信息： 内容范围： 本文档是软件系统JAVA编码规范。适用的对象： 公司相关技术人员。
目录 1 介绍（INTRODUCTION） (5) 2 2 文件名（FILE NAMES） (6) 2.1文件后缀（F ILE S UFFIXES） (6) 2.2常用文件名（C OMMON F ILE N AMES） (6) 3 文件组织（FILE ORGANIZATION） (7) 3.1J AVA源文件（J AVA S OURCE F ILES） (7) 3.1.1开首注释（B EGINNING C OMMENTS） (7) 3.1.2包和引入语句（P ACKAGE AND I MPORT S TATEMENTS） (8) 3.1.3类和接口声明（C LASS AND I NTERFACE D ECLARATIONS） (8) 4 缩进排版（INDENTATION） (9) 4.1行长度（L INE L ENGTH） (9) 4.2换行（W RAPPING L INES） (9) 5 注释（COMMENTS） (13) 5.1实现注释的格局（I MPLEMENTATION C OMMENT F ORMATS） (13) 5.1.1块注释（B LOCK C OMMENTS） (13) 5.1.2单行注释（S INGLE-L INE C OMMENTS） (14) 5.1.3尾端注释（T RAILING C OMMENTS） (15) 5.1.4行末注释（E ND-O F-L INE C OMMENTS） (15) 5.2文档注释（D OCUMENTATION C OMMENTS） (16) 6 声明（DECLARATIONS） (17) 6.1每行声明变量的数量（N UMBER P ER L INE） (17) 6.2初始化（I NITIALIZATION） (17) 6.3布局（P LACEMENT） (17) 6.4类和接口的声明（C LASS AND I NTERFACE D ECLARATIONS） (18) 7 语句（STATEMENTS） (20) 7.1简单语句（S IMPLE S TATEMENTS） (20) 7.2复合语句（C OMPOUND S TATEMENTS） (20)
Java 开发规范文档 一：目的 使本组织能以标准的，规范的方式设计和编码。通过建立编码规范，以使每个开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程序的可靠性，可读性，可修改性，可维护性和一致性等，增进团队间的交流，并保证软件产品的质量。 二：代码组织与风格 1：长度：为便于阅读和理解，单个函数的有效代码长度当尽量在100行以内（不包括注释行），当功能模块过大时往往采用使用子函数将相应的功能抽取出来，这也有利于提高代码的重用度。 2：单个类不宜过大，当出现此类过大时当将相应功能的代码重构到其他类中，通过组合等方式来调用，建议单个类的长度包括注释行不超过1500行。尽量避免使用大类和长方法。3：间隔：类，方法及功能块间等应以空行相隔，以增加可读性，但不得有无规则的大片空行。操作符两端应当各空一个字符以增加可读性。 三：注释 1：注释应该增加代码的清晰度。代码注释的目的时要使代码更易于被其他开发人员等理解。2：保持注释的简洁。 3：注释信息应该包括代码的功能。 4：除变量定义等较短语句的注释使用行尾注释外，其他注释当避免使用行尾注释。 5：JavaDoc规范 对类，方法，变量等注释需要符合javadoc规范，对每个类，方法都应详细说明其功能条件，参数等。类注释中应当包含版本和作者信息。 1）类，接口注释在类，接口定义之前当对其进行注释，包括类，接口的目的，作用，功能，继承于何种父类，实现的接口，实现的算法，使用方法，示例程序等。 2）方法注释以明确该方法功能，作者，各参数含义以及返回值等。
3）其他注释应对重要的变量及不易理解的分支条件表达式加以注释，以说明其含义等。四命名规范 1：对变量，类，接口及包的命名应该使用英文。严禁使用汉语拼音及不相关单词命名。更不可以使用汉字来进行命名。采用大小写混合，提高名字的可读性。一般应该采用小写字母，但时类和接口的名称的首字母，以及任何中间单词的首字母应该大写。包名全部小写。 2：尽量少用缩写，但如果一定要用，当使用公共缩写和习惯缩写等，如implement可缩写为impl，manager可缩写成mgr等。 3：包名一般以项目或模块名命名，少用缩写和长名，一律小写。 包名按照如下规定组成[基本包].[项目名].[模块名].[子模块名].…. 如：org.skyinn.skyhome.dao.hibernate。 不得将类直接定义在基本包下，所有项目中的类，接口等都当定义在各自的项目和模块包中。 4：类，接口所有单词首字母大写，最好能够见名知意。一般采用名词。接口可带I前缀。 或able，dao后缀。 5：字段常量采用完整的英文大写单词，单词之间用下划线连接，如DEFAULT_V ALUE. 6：变量和参数对不易识别出该变量类型的变量应使用类型缩写作其前缀，如字符串使用strXXX，boolean使用isXXX，hasXXX等等。除第一个单词外其余单词的首字母大写。7：集合采用复数名称来表示队列中存放的对象类型，名词采用完整的英文描述。 例如：Vector vProducts= new Vector(); Array aryUsers= new Array(); 8：方法方法的名称应采用完整的英文描述，大小写混合使用：所有中间单词的第一个字母大写。方法名称的第一个单词常常采用一个强烈动作色彩的动词。取值类使用get前缀，设置类使用set前缀。例如getName（），setSarry（）。 9：异常类名由表示该异常类型的单词和Exception组成，如ActionException。异常实例一般使用e，ex等。 10：数组的命名 数组应该总是用下面的方式来命名：byte[] buffer; 而不是：byte buffer[]; 五：类与接口 1：基本原则：一个类只做一件事情。另一个原则时根据每个类的职责进行划分，比如用User 来存放用户信息，而用UserDAO来对用户信息进行数据访问操作，用UserServer对用户信息的业务操作等等。多个类中使用相同方法时将其方法提到一个接口中或使用抽象类，尽量提高重用度。不希望被实例化的类的缺省构造方法声明为private。 2：一般而言，接口定义行为，而抽象类定义属性和共有行为，注意2者的取舍，在设计中可由接口定义公用的行为，由一个抽象类来实现其部分或全部方法，以给子类提供统一的行为为定义。 六：方法 一个方法只完成一项功能。方法参数类型和参数返回值尽量接口化，以屏蔽具体的实现细节，提高系统的可扩展性，例如：public void addUser（List userList）{} public List listAllUsers（）{} 七：Web 命名规范 一：jsp页面命名 对于某个功能块的增删改查页面定义，最好使用
Java编程规范本文引用阿里Java开发手册。GitHub阅读地址： 目录 编程规约 - 命名规约 - 常量定义 - 格式规范 - OOP规约 - 集合处理 - 并发处理 - 控制语句 - 注释规约 - 其他 - 异常处理 - 建表规约 - 索引规约 - SQL规约
- ORM规约 编程规约 命名规约 1、【强制】所有编程相关命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束 反例： _name / __name / $Object / name_ / name$ / Object$1 2、【强制】所有编程相关的命名严禁使用拼音与英语混合的方式，更不允许直接使用中的方式。 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即纯拼音的命名方式也要避免采用。 反例： DaZhePromotion [打折] / getPingfenByName() [评分] / int 变量 = 3; 正例： ali / alibaba / taobao / cainiao / aliyun / youku / hangzhou 等国际通用的名称，可视为英文。12345 3、【强制】类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名） DO / DTO / VO / DAO 等。 正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例： macroPolo / UserDo / XMLService / TCPUDPDeal
/ TAPromotion123 4、【强制】方法名、参数名、成员变量、局部变量都统一只用 lowerCamelCase 风格，必须遵从驼峰形式。 正例： localValue / getHttpMessage() / inputUserId1 5、【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。 正例： MAX_STOCK_COUNT 反例： MAX_COUNT123 6、【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。 7、【强制】中括号是数组类型的一部分，数组定义如下：String[] args ; 反例：请勿使用 String args[] 的方式来定义1 8、【强制】 POJO 类中的任何布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。 反例：定义为基本数据类型 boolean isSuccess；的属性，它的方法也是 isSuccess()， RPC框架在反向解析的时候，“以为”对应的属性名称是 success，导致属性获取不到，进而抛出异常。1 9、【强制】包名统一使用小写，点分隔符之间有且仅有一
JAVA编程规范--试题 姓名：工号：部门：成绩： 一. 判断题（共15题，每题2分，直接在括号内打“√”或“×”） 1、任何时候都不要使接口可以序列化。x 2、相对独立的程序块之间、变量说明之后必须加空行。√ 3、当程序需要释放对象的时候，应该手工调用finalize方法以释放对象。x 4、公司的规范要求注释率是20％以上，并且必须有助于对程序的阅读理解。x 5、为了程序更加简洁，我们应该尽量使用下面的方式来赋值：a = b = 1 。x 6、每个类都需要定义构建器。x 7、类名、方法名、属性名的命名，都应该使用意义完整的英文描述。√ 8、main() 方法的定义是public static void main(String args[])。x 9、常量名应该使用全大写，英文单词之间用下划线或者-分隔开。并且，常量应该使用final static修饰。x 10、公有方法参数名可以和属性名相同，但局部变量不能和属性名相同。√ 11、一两行代码就能完成的功能没有必要编写方法实现。x 12、对于模块间接口方法的参数的合法性检查，调用者和被调用者都应该对参数进行合法性检查。 x 13、运行期异常使用RuntimeException的子类来表示，必须在方法声明上加throws子句。x非运 行期异常是从Exception继承而来的，不用在可能抛出异常的方法声明上加throws子句。x 14、使用ObjectStream 的方法后，调用release() ，释放对象。X 15、减小单个方法的复杂度，使用的 if, while, for, switch 语句要在10个以内。√ 二、单项选择题(共23题，每题2分) （ c ）1、排版时，代码缩进应该采用的方式是： （A）Tab缩进 （B）2个空格缩进 （C）4个空格缩进 （D）8个空格缩进
项目团队开发规范
修订历史记录
目录 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 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。
Java web开发规范 1、前言 为了使软件开发过程有章可循，保证软件质量，加强开发管理。 2、开发管理 项目进度周报表格如下： 项目编号汇报人汇报日期项目进度详细描述其他问题 3、命名规范 3.1项目编号命名规范 命名方式：项目英文/中午拼音名称_开发组编号_序列号 序列号由3为数字组成，不足的用’0’补齐。 3.2文档命名规范 命名方式：项目英文/中午拼音名称_文档名称_序列号_编写人名称/编号 3.3jsp/html命名规范 1、jsp与html文件名全部小写，并遵循如下的规范： a.数据/内容显示页: 名词，多个单词用下划线分隔，要求能说明显示内容的信息，为避免冲突，可加上“_list”。例如： new_message.html或my_file_list.jsp b.操作处理页 命名格式：名词_下划线_动词，例如：file_delete.jsp。 c.含frame页面