Java后台项目开发规范

写在前边
- 1、目标
- 2、原则
一、命名规范
- 1、包命名规范
- 2、类命名规范【**UpperCamelCase命名法**】
- - 2.1==如果在模块或者接口，类，方法中使用了设计模式，要在命名的时候体现出来。==
  - 2.2 对于任何类而言，只要重写了equals就必须重写hashcode
- 3、接口命名规范
- 4、接口实现类命名
- 5、方法命名规范【**lowerCamelCase命名法**】
- 6、类变量命名【**lowerCamelCase命名法**】
- 7、常量命名
二、注释规范
- 1、说明
- 2、关键点注释
- 3、javadoc注释标签语法定义说明
- 4、基本格式
三、格式规范
- 1、缩进
- 2、换行
- 3、对齐
- 4、空格的使用
- 5、equals() 和 hashcode()
- 6、习惯
四、异常的处理
写在后边

写在前边

1、目标

项目以功能模块来划分分工
数据库不能随意修改，本地数据库须统一
有标准的Java代码风格，有良好习惯
时刻考虑代码的可复用性
每个人需要有每周项目进度报告

2、原则

标识符的命名力求做到统一、达意和简洁

2.1 统一

统一是指，对于同一个概念，在程序中用同一种表示方法，比如对于供应商，既可以用supplier，也可以用provider，但是我们只能选定一个使用，至少在一个Java项目中保持统一。统一是作为重要的，如果对同一概念有不同的表示方法，会使代码混乱难以理解。即使不能取得好的名称，但是只要统一，阅读起来也不会太困难，因为阅读者只要理解一次。

2.2 达意

达意是指，标识符能准确的表达出它所代表的意义，比如： newSupplier, OrderPaymentGatewayService等；而 supplier1, service2，idtts等则不是好的命名方式。准确有两成含义，一是正确，而是丰富。如果给一个代表供应商的变量起名是 order，显然没有正确表达。同样的，supplier1, 远没有targetSupplier意义丰富。

2.3简洁

简洁是指，在统一和达意的前提下，用尽量少的标识符。如果不能达意，宁愿不要简洁。比如：theOrderNameOfTheTargetSupplierWhichIsTransfered 太长， transferedTargetSupplierOrderName则较好，但是transTgtSplOrdNm就不好了。省略元音的缩写方式不要使用，我们的英语往往还没有好到看得懂奇怪的缩写。

2.4 骆驼法则

Java中，除了包名，静态常量等特殊情况，大部分情况下标识符使用骆驼法则，即单词之间不使用特殊符号分割，而是通过首字母大写来分割。比如: supplierName, addNewContract，而不是 supplier_name, add_new_contract。

2.5 英文拼音

尽量使用通俗易懂的英文单词，如果不会可以谷歌，避免拼音与英文混用。比如表示归档，用archive比较好, 用pigeonhole、guiDang则不好。

一、命名规范

尽量保证能够通过变量名得知变量的含义

1、包命名规范

目的：包的命名规范应当体现出****项目资源良好的划分****

自定义标签类所在包命名规范：com.****项目名称**(小写)****.tags

包命名采用全小写命名
通过唯一域名+组件来命名

// <projectname>为项目英文简称或缩写；
// <modulename>为模块英文名称或简称，如果无细分模块的话可省略模块名
net.javaing.<projectname>.<modulename>

2、类命名规范【UpperCamelCase命名法】

命名规范：以大写字母开头，如果有多个单词，每个单词头字母大

后缀名	意义	举例
Service	表明这个类是个服务类，里面包含了给其他类提同业务服务的方法	UserService
Impl	这个类是一个实现类，而不是接口	UserServiceImpl
Dao（Mapper）	这个类封装了数据访问方法	UserDao
Action	直接处理页面请求，管理页面逻辑了类	UpdateOrderListAction
Listener	响应某种事件的类	PaymentSuccessListener
Event	这个类代表了某种事件	PaymentSuccessEvent
Servlet	一个Servlet	PaymentCallbackServlet
Factory	生成某种对象工厂的类	UserFactory
Adapter	用来连接某种以前不被支持的对象的类	DatabaseLogAdapter
Job	某种按时间运行的任务	UserCancelJob
Wrapper	这是一个包装类，为了给某个类提供没有的能力	SelectableOrderListWrapper

2.1如果在模块或者接口，类，方法中使用了设计模式，要在命名的时候体现出来。

public class TokenFactory {    public TokenDTO buildToken(LoginInfo loginInfo) {        String token = UUID.randomUUID().toString();       TokenDTO tokenDTO = TokenDTO.builder().token(token)             .createTime(LocalDateTime.now()).build();        String redisKey = RedisKeyBuilder.buildTokenKey(token);        redisService.setObject(redisKey, loginInfo, Timeout.ONE_DAY * 30 * 2);        log.info("创建token成功|loginInfo={}", loginInfo.toString());        return tokenDTO;    }
}

2.2 对于任何类而言，只要重写了equals就必须重写hashcode

举例说明:

1）HashSet在存储数据的时候是存储不重复对象的，这些对象在进行判断的时候需要依赖hashcode和equals方法，因此需要重写。

2）在自定义对象作为key键时，需要重写hashcode和equals方法，例如说String类就比较适合用于做key来使用。

3、接口命名规范

命名规范：建议以大写字母"I"开头，如果有多个单词，每个单词头字母大写

例如：****IStudentInfo****

//类、接口定义语法规范
[可见性][('abstract'|'final')] [Class|Interface] class_name[('extends'|'implements')][父类或接口名]{//方法体}

4、接口实现类命名

命名规范：将实现的接口名称的首字母"I"去掉，以"Impl作为结尾"，如果有多个单词，每个单词头字母大写。

例如：****StudentInfoImpl****

5、方法命名规范【lowerCamelCase命名法】

命名规范：小写字母开头，各个单词首字母大写

属性的getter和setter方法尽量使用自动生成，并放在程序的后面。
Boolean类型的属性的get方法应形如isProperty()

// 语法
[可见性]['abstract'] [‘static’] ['final'] ['synchronized'][返回值类型] method_name(参数列表)[('throws')][异常列表]{//方法体}

前缀名	意义	举例
save	创建	saveOrder()
delete	删除	deleteOrder()
add	创建，暗示新创建的对象属于某个集合	addPaidOrder()
remove	删除	removeOrder()
init或则initialize	初始化，暗示会做些诸如获取资源等特殊动作	initializeObjectPool
destroy	销毁，暗示会做些诸如释放资源的特殊动作	destroyObjectPool
open	打开	openConnection()
close	关闭	closeConnection()<
read	读取	readUserName()
write	写入	writeUserName()
get	获得	getName()
set	设置	setName()
prepare	准备	prepareOrderList()
copy	复制	copyCustomerList()
modity	修改	modifyActualTotalAmount()
calculate	数值计算	calculateCommission()
do	执行某个过程或流程	doOrderCancelJob()
dispatch	判断程序流程转向	dispatchUserRequest()
start	开始	startOrderProcessing()
stop	结束	stopOrderProcessing()
send	发送某个消息或事件	sendOrderPaidMessage()
receive	接受消息或时间	receiveOrderPaidMessgae()
respond	响应用户动作	responseOrderListItemClicked()
find	查找对象	findNewSupplier()
fetch	获取对象	fetch()
update	更新对象	updateCommission()
to	到达	toAddUser()

6、类变量命名【lowerCamelCase命名法】

命名规范：

变量名首字母必须小写，如果该变量名有多个单词组成，后面的单词首字母大写；

单词与单词之间不要使用"_"做连接，

变量名访问控制必须为私有，可以对其增加setter与getter方法。

特有大写缩写词汇保持大写如：SQL
变量名字不宜过长，可适当采用缩减英文元音字母来缩短长度
假如缩短后名字重复，可以保留其中一个的部分元音字母

7、常量命名

命名规范：采用全大写命名法，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长

static final int MIN_WIDTH = 4；

二、注释规范

1、说明

一些程序关键的地方
一些程序不易读的地方
编写代码过程中遇到问题的地方
需要提示读者的地方

2、关键点注释

注释要精简并清晰容易理解，而且一定要和代码保持同步

代码质量不好但能正常运行，或者还没有实现的代码用 //TODO:任务 ；
存在错误隐患的代码用 //FIXME:声明；
对于不建议使用（废弃）的类或者方法，必须在他们的注释中增加@deprecated；
若修改了文件，可以加上修改人的信息，和修改日期。

3、javadoc注释标签语法定义说明

@author 对类的说明 标明开发该类模块的作者
@version 对类的说明 标明该类模块的版本
@see 对类、属性、方法的说明 参考转向，也就是相关主题
@param 对方法的说明 对方法中某参数的说明
@return 对方法的说明 对方法返回值的说明
@exception 对方法的说明 对方法可能抛出的异常进行说
@deprecated 对类或方法的说明 该类或方法不建议使用

详情参考JavaDoc文档注释

4、基本格式

//单行注释格式
/*多行注释格式
*/

三、格式规范

1、缩进

应注意使用format来格式化代码，使用Tab键来缩进代码，相当于4个空格。

2、换行

{}花括号应该另起一行，左花括号与方法名、类名在同一行。(除了数组初始化时的花括号)
if、while等语句，假如体内只有一句代码也不要省略{}，为了方便以后的增删
字符串过长考虑拆分成多行

3、对齐

{}括号等应该对齐
类和方法的块注释必须紧贴类和方法
单独起行的//注释必须对齐被注释语句

4、空格的使用

等号左右必须各有一个空格：

button = null;
双目运算符左右必须各有一个空格：
imageWidth = imagePadding + imageSize;
标点符号后面必须跟一个空格
- 一行定义多个变量时，“,”后跟空格：
  int i, j;
- 在for循环中，“;”后跟空格：
  for (int i = 0; i < count; ++i){}
- 在有多个入口参数的函数调用中，“,”后跟一个空格：
  addContentView(view, params);

5、equals() 和 hashcode()

比较字符串时,常量永远放在左边
- 所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。(注意空指针)

因为 Set 存储的是不重复对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须重写这两方法。
如果自定义对象做为 Map 的键，那么必须重写 hashCode 和 equals 。

常用的如String和Integer默认已经重写了这两个方法。

6、习惯

if、for、do、while等语句的执行语句部分无论多少都要加括号"{}"
每当一个case顺着往下执行时(因为没有break语句)，通常应在break语句的位置添加注释；
尽量避免在循环中构造和释放对象；
在使用局部变量的过程，按就近原则处理。不允许定义一个局部变量，然后在很远的地方才使用；
相同的功能不允许复制成N份代码；
在处理 String 的时候要尽量使用 StringBuffer 类。

四、异常的处理

捕捉异常的目的是为了处理它
多个异常应分别捕捉并处理，避免使用一个单一的catch来处理。
重新抛出的异常必须保留原来的异常：

正确：throw new NewException(“message”, e);

   错误：`throw new NewException(“message”)`，**更不能不继续往上层抛出异常**。

【推荐】针对重要的可捕获的业务相关异常，需创建异常处理类，在方法中捕获到异常后，反馈到用户界面上，提示用户。

写在后边

代码在提交版本控制之前，请确保已清除不必要的log调试语句
明确的垃圾或无用代码必须删除

详情参考：阿里开发规范终极版整理(精简)