Java编码规范

1. 命名规约
  • 抽象类命名使用Abstract或Base开头
  • 异常类命名使用Exception结尾
  • 测试类命名以它要测试的类的名称开始,以Test结尾
  • 中括号是数组类型的一部分,数组定义如下:string[] args;
  • POJO类中,布尔类型的变量都不要加is,否则部分框架解析会引起序列化错误
  • 接口类中的方法和属性不要加任何修饰符号(public也不要加),保持代码的简洁性,并加上有效的Javadoc注释
  • 对于Service和DAO层,基于SOA的理念,暴露出来的服务一定是接口,内部的实现类用Impl的后缀与接口区别
  • Service/DAO层命名规约
    • 获取单个对象的方法用get做前缀
    • 获取多个对象的方法用list做前缀
    • 获取统计值的方法用count做前缀
    • 插入方法用save(推荐)或insert做前缀
    • 删除方法用remove(推荐)或delete做前缀
    • 修改的方法用update做前缀
  • 领域模型命名规范
    • 数据模型:xxxDO,xxx表示数据表名
    • 数据传输对象:xxxDTO,xxx为业务领域相关的名称
    • 展示对象:xxxVO,xxx一般为网页名称
    • POJO是DO/DTO/BO/VO的统称,禁止命名为xxxPOJO

用户发出请求(可能是填写表单),表单的数据在展示层被匹配为VO。

展示层把VO转换为服务层对应方法所要求的DTO,传送给服务层。

服务层首先根据DTO的数据构造(或重建)一个DO,调用DO的业务方法完成具体业务。

服务层把DO转换为持久层对应的PO(可以使用ORM工具,也可以不用),调用持久层的持久化方法,把PO传递给它,完成持久化操作。

对于一个逆向操作,如读取数据,也是用类似的方式转换和传递,略。

2.OOP规约
  • 避免通过一个类的对象引用访问此类的静态变量或静态方法,无谓增加编译器解析成本,直接用类名访问即可
  • 所有的覆写方法,必须加@Override注解
  • 尽量不用可变参数编程。如果使用,相同参数类型,相同业务含义,才可以使用可变参数,避免使用Object
  • 不能使用过时的类或方法
  • 所有相同类型的包装类对象之间值比较,全部使用equals方法比较。对于-128~127之间的Integer值,可以使用==进行值比较(这个区间Integer对象是在IntegerCache.cache产生,会复用已有对象。但是这个区间外的所有数据都会在堆上产生,并不会复用已有对象)
  • 定义DO/DTO/VO等POJO类时,不要设定任何属性默认值
  • 序列化类新增属性时,请不要修改serialVersionUID字段,避免反序列失败;如果完全不兼容升级,避免反序列化混乱,那么请修改seriaVersionUID
  • 构造方法里面禁止加入任何业务逻辑,如果有初始化逻辑,请放在init方法中
  • POJO类必须写toString方法
  • 类成员与方法访问控制从严
    • 如果不允许外部直接通过new来创建对象,那么构造方法必须是private
    • 工具类不允许有publicdefault构造方法
    • 类非static成员变量并且与子类共享,必须是protected
    • 类非static成员变量并且仅在本类使用,必须是private
    • static成员变量如果仅在本类使用,必须是private
    • 若是static成员变量,必须考虑是否为final
    • 类成员方法只供类内部调用,必须是private
    • 类成员方法只对继承公开,那么限制为protected
3.集合处理
  • 关于hashCodeequals
    • 只要重写equals,就必须重写hashCode
    • 因为Set存储的是不重复的对象,依据hashCodeequals判断,所以Set存储的对象必须重写这两个方法
    • 如果自定义对象作为Map键,那么必须重写hashCodeequals
    • String重写了hashCodeequals方法,所以我们可以愉快地使用String对象作为key来使用
  • 不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式,如果并发操作,需要对Iterator对象加锁
  • 使用entrySet遍历Map集合KV,而不是keySet方式进行遍历
4.注释规约
  • 类、类属性、类方法的注释必须使用Javadoc规范,不得使用//XXXX方式
  • 所有的抽象方法(包括接口中的方法)必须要用Javadoc注释、除了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能
  • 所有的类必须添加创建者信息
  • 所有的枚举类型字段必须要有注释,说明每个数据项的用途
5.异常处理
  • 不要捕获Java类库中定义的继承自RuntimeException的运行时异常类,如:IndexOutOfBoundsException/NullPointerException,这类异常由程序员预检查来规避,保证程序健壮性
  • 异常不要用来做流程控制、条件控制,因为异常的处理效率比条件分支低
  • 对大段代码进行try-catch,这是不负责任的表现,对于非稳定代码的catch尽可能进行区分异常类型,再做对应的异常处理
  • finally块必须对资源对象、流对象进行关闭,有异常也要做try-catch
  • 不能在finally块中使用return。finally块中的return返回后方法结束执行,不会再执行try块中的return语句
  • 防止NPE
    • 返回类型为包装数据类型,有可能是null
    • 数据库的查询结果有可能为null
    • 集合里的元素即使isNotEmpty,取出的数据元素也可能为null
    • 远程调用返回对象,一律要求进行NPE判断
    • 对于Session中获取的数据,建议NPE检查,避免空指针
    • 级联调用容易产生NPE。如obj.getA().getB().getC()
6.MySQL规约
6.1 建表规约
  • 表达概念的字段,必须使用is_xxx的方式命名,数据类型是unsigned tinyint(1表示是,0表示否)
  • 表名、字段名必须使用小写字母或数字;禁止出现数字开头,禁止两个下划线中间只出现数字。
  • 表名不使用复数名词
  • 唯一索引为uk_字段名;普通索引则为inx_字段名
  • 小数类型为decimal,禁止使用doublefloat
  • 表必备三字段:id、create_at、update_at
  • 表的命名最好是加上业务名称_表的作用
  • 库名与应用名称尽量一致
  • 字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。同时冗余字段应
    • 不是频繁修改的字段
    • 不是varchar超长字段,更不能是text字段
6.2 索引规约
  • 业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引
  • 超过三个表禁止join。需要join的字段,数据类型保持绝对一致;多表关联查询时,保证被关联的字段需要有索引
  • varchar字段上建立索引时,必须制定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度
  • 页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决
  • 如果有order by的场景,请注意利用索引的有序性。order by最后的字段是组合索引的一部分,并且放在索引组合顺序的最后,避免出现file _ sort的情况,影响查询性能
  • 利用覆盖索引来进行查询操作,来避免回表操作
  • 利用延迟关联或者子查询优化超多分页场景
  • 建组合索引的时候,区分度最高的在最左边
  • 创建索引时避免有如下极端误解
    • 误认为一个查询就需要建一个索引
    • 误认为索引会消耗空间、严重拖慢更新和新增速度
    • 误认为唯一索引一律需要在应用层通过“先查后插”方式解决
6.3 SQL
  • 不要使用count(列名)count(常量)来替代count(*)count(*)就是 SQL 92 定义的标准统计行数的语法,跟数据库无关,跟 NULL 和非 NULL 无关
    • count(*)会统计值为 NULL 的行,而count(列名)不会统计此列为 NULL 值的行
  • count(distinct col)计算该列除 NULL 之外的不重复数量。注意count(distinctcol 1, col 2) 如果其中一列全为 NULL ,那么即使另一列有不同的值,也返回为 0
  • 不得使用外键与级联,一切外键概念必须在应用层解决
  • 禁止使用存储过程,存储过程难以调试和扩展,更没有移植性
  • 数据订正时,删除和修改记录时,要先select,避免出现误删除,确认无误才能执行更新语句
  • in操作能避免则避免,若实在避免不了,需要仔细评估in后边的集合元素数量,控制在1000个之内
  • TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但 TRUNCATE无事务且不触发 trigger ,有可能造成事故,故不建议在开发代码中使用此语句
6.4 ORM规约
  • 在表查询中,一律不要使用*作为查询的字段列表,需要哪些字段必须明确写明
  • POJO 类的boolean属性不能加is,而数据库字段必须加is _,要求在resultMap中进行字段与属性之间的映射
  • 不要用 resultClass 当返回参数,即使所有类属性名与数据库字段一一对应,也需要定义 ; 反过来,每一个表也必然有一个与之对应
  • xml 配置中参数注意使用:#{},# param # 不要使用${} 此种方式容易出现 SQL 注入
  • 不允许直接拿HashMapHashtable作为查询结果集的输出
  • 更新数据表记录时,必须同时更新记录对应的gmt _ modified(update_at)字段值为当前时间
  • 不要写一个大而全的数据更新接口,传入为 POJO 类,不管是不是自己的目标更新字段,都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL时,尽量不要更新无改动的字段,一是易出错 ; 二是效率低 ; 三是 binlog 增加存储
  • @ Transactional 事务不要滥用。事务会影响数据库的 QPS ,另外使用事务的地方需要考虑各方面的回滚方案,包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值