JAVA代码规范之于java开发程序员就是开发代码的习惯,就想空气(AIR) 与 呼吸(BREATHE)一样,平常。
有追求的程序员希望码完的代码优雅获得认可,这可不是一件容易的事情。每当代码评审的时候,总会容易挑出一些缺少的或者过分的代码,比如会思考参数校验在dao层需不需要的问题。
《阿里巴巴JAVA开发手册》之前虽然看过一遍,但并没有详细的理解与运用到开发中来。
让我们再来重温一下,借鉴阿里众多前辈们对于书写易维护易阅度而又优雅的代码的心得吧。
一、编程规约
--命名风格
主要要求做到见名知意 驼峰命名, 不要自以为是的缩写 中英混搭 不伦不类
着重(Tips)注意第8点
【强制】POJO 类中布尔类型的变量,都不要加 is,否则部分框架解析会引起序列化错误。
反例:定义为基本数据类型 Boolean isDeleted;的属性,它的方法也是 isDeleted(),RPC
阿里巴巴 Java 开发手册
——禁止用于商业用途,违者必究—— 2 /35
框架在反向解析的时候,“以为”对应的属性名称是 deleted,导致属性获取不到,进而抛出异
常。
着重(Tips)注意第16点
A) Service/DAO 层方法命名规约
1) 获取单个对象的方法用 get 做前缀。
2) 获取多个对象的方法用 list 做前缀。
3) 获取统计值的方法用 count 做前缀。
4) 插入的方法用 save/insert 做前缀。
5) 删除的方法用 remove/delete 做前缀。
6) 修改的方法用 update 做前缀。
--常量定义
不要将魔法值直接写在代码中。思考你希望该常量的作用域在类 包(default 常量类) 模块(public 常量类) 工程(依赖 commons项目下的常量类) 还是跨应用间调用
最简单的当然是在类中直接定义,但这会导致在多处引用的时候修改困难,不移维护。
--代码格式
自己看下手册中的内容,对比自己的习惯优化下
--OOP规约
第8点 在pojo类中 基本数据类型尽量不去使用。在对数据库记录的映射,在RPC传输过程中 不是只有值的 -1 0 1 的问题 还有一个 IS NULL 的问题。尽量使用包装类。
这个说明非常好,任何NPE问题或者入库检查,都由调用者来保证。
我是这么理解的,当然希望各位大佬能够指正:
action/manager/RPC接口 主要对于入参进行校验,
在pojo类中,不要想着含有逻辑,尽管可能因为会用到观察者模式而窃喜,但这会增加排查的难度。
着重注意第20点。不要一昧的 public ,不要让自己的孩子失控。
--集合处理
arrayList.sublist(startIndex,endIndex); 不再是ArrayList了是其视图(内部类)。使用 Collections.copy()
List list=Arrays.asList() ; 不能进行增删操作
第9点 集合初始化时,指定初始值大小 initialCapacity = (需要存储的元素个数 / 负载因子) + 1 loadFactory=0.75
-_- 我以前是直接 赋值 initialCapacity=需要存储的元素个数。 虽然有疑惑 但还是这样做了。 lol:这么久了,改正一点也很开心
第10点 get(key) 本身遍历一次树,生成 keySet() 需要遍历一次树 要用2次? come on! 要多干活怎么会乐意呢
--并发处理
--控制语句
第3点 超过3层的if else 语句使用卫语句、策略模式、状态模式
第6点 接口入参保护,这种场景常见的是用作批量操作的接口。
很简单的一句话,我几乎都忽略了,baidu了一下,你会有所收获。:作为服务端,我不是无脑的接收调用端的请求,你要我一天干10天的活,我受不了的,果断要拒绝呀。
最常见的做法就是入参校验,有效值的范围,白名单的设置。
二、异常日志
--异常处理
主要提醒了不要过度依赖进行流程的控制, 例如null判断,防止 NPE
--日志规约
第4点 【强制】对 trace/debug/info 级别的日志输出,必须使用条件输出形式或者使用占位符的方
式。
说明:logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
如果日志级别是 warn,上述日志不会打印,但是会执行字符串拼接操作,如果 symbol 是对象,
会执行 toString()方法,浪费了系统资源,执行了上述操作,最终日志却没有打印。
正例:(条件)
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
正例:(占位符)
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
第6点 我以前的日志
logger.error("类名:方法名 {}" ,e.getMessage()) 看起来总缺点什么
以后这样弄了 logger.error("类名:方法名 {}" +e.getMessage(),e)
V MySQL数据库 (尽管能够在各类MySQL书籍上学到,但具体的标准很少有指明,膜拜一下吧)
-建表规约
第1点 任何字段如果为非负数,必须是 unsigned ; 删除数据 真删除 你就完蛋了 采用逻辑删除过滤数据 1 已删除 0未删除
第2点 表名字段名必须使用小写字母或数字 目前我们的数据库 字段名是存在大小写的,但是未曾有过问题。这种大神级问题如何避免
其他方式不知道,(也许是我们的编码习惯良好,字段很是对应吧) 记住,当你成为设计表的那个人,自己就可以偷着乐了吧
第7点 如果存储的字符串长度几乎相等,使用 char 定长字符串类型。 优化的细节问题。如果你是个注重细节的人 注意他,会成为你的内涵
第8点 varchar 是可变长字符串,不预先分配存储空间,长度不要超过 5000,如果存储长
度大于此值,定义字段类型为 text,独立出来一张表,用主键来对应,避免影响其它字段索
引效率。 具体的临界值标准 给了,有经验了吧
第14点【推荐】单表行数超过 500 万行或者单表容量超过 2GB,才推荐进行分库分表。
说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。
网上各种 说百万级数据 到底多少呢 它leile
-索引规约
这个强烈建议阅度记忆
第3点在 varchar 字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据
实际文本区分度决定索引长度即可。
说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为 20 的索引,区分
度会高达 90%以上,可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度
来确定。 //这个说明要给个满分
第5点 【推荐】如果有 order by 的场景,请注意利用索引的有序性。order by 最后的字段是组合
索引的一部分,并且放在索引组合顺序的最后,避免出现 file_sort 的情况,影响查询性能。
正例:where a=? and b=? order by c; 索引:a_b_c
反例:索引中有范围查找,那么索引有序性无法利用,如:WHERE a>10 ORDER BY b; 索引
a_b 无法排序。
//或许你也曾跟我一样傻傻的认为 a | b | c 有一个索引就ok了 -_- 确实有效果,但a | b | c 区分度不高的情况怎么办呢?
那单独建不了索引,就需要一个组合索引来帮忙了
第7点 属于分页的优化 要么控制返回的总页数 //什么鬼? 细想想 我们可以在适当的场景让部分不可阅啊 被关小黑屋 但总感觉这场景变扭
先快速定位需要获取的 id 段,然后再关联:
SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
-SQL语句
第1点 count(列) count(常量) count(1) count(*) 四者的区别 网上好好查查吧
列值为null的记录 查不出 效率问题 内置count(1) 等价于 count(*) 但是效率略高 选哪个知道了吧 就是 No1
第2点
=================================================总结以上=================================================
++++++++++++++++++++++++++++++++++++++其他的各位大佬要自己认真看哦++++++++++++++++++++++++++++++++++++++