CR总结--java函数CR

序号	问题	建议
1	圈复杂度	不超过10
2	synchronized的范围	控制范围，缩小粒度
3	出现伪重载，多个不同修饰符	重载函数的修饰一致
4	参数多	不超过5个，多个合并为个参数类
5	加锁必要性	如果非多线程使用场景，去掉锁
6	容器类如StringBuilder，hashMap制定预设大小
7	优先使用JDK工具函数
8	锁对象选择	最优是new byte[0]作为锁对象
9	类的对外接口个数，即函数的修饰是否合理	不要一股脑的public，控制对外暴露的风险
10	判断逻辑里条件个数太多，理解困难	判断逻辑里超过4个即整理为一个独立函数
11	资源释放问题	在finally或1.8后的try
12	函数逻辑规整	使用空格 归类逻辑
13	函数名	见名知意，首先要使用正确的单词；不能太长，太长也意味函数包含太多逻辑；设置/获取数值型的函数名称需要带上数值单位
14	函数的抛出异常	需要在注释里说明，或者使用throws
15	有效代码行数	40
16	无效代码清理
17	局部变量距离最近使用	不超过3行
19	防范式编程	异常或值校验，要先做，尤其是对外接口
20	注释	public 必须注释
21	方法逻辑清晰	功能单一和函数名称切合，如有修改逻辑及时修改注释
22	对之前版本的兼容	对外接口函数，旧函数如果要替换，需要一个弃用过程，并提示替换的方案
23	参数名称	见名知意，参数如果有多个单位层级，需要独立一个参数表示单位，如时间单位，磁盘大小的单位
24	函数功能的对称性，如有	如add 就要remove，init 对应destroy
25	防止死锁，查看锁对象的应用位置
26	使用线程池	控制线程大学，和任务队列大小，Exctors方法谨慎使用。
27	多算法的合理组合	如快速排序是286个以下，以上就使用合并排序
28	函数参数的信息量太大，不可测，如一个对象传进来，只是使用了对象的一个属性	坚持够用就好
29	入参数被修改	不要修改入参，和C/C++相反，如有修改是拷贝副本，处理后再return
30	多个判断逻辑混乱，出现执行路径不可达或重复执行
31	跨平台传输数值	使用String方法，尤其是浮点数
32	JNI/NDK的内存回收问题	全局引用（Global reference），局部引用（Local reference），弱全局引用（Weak global reference）。 全局引用的生存期为创建之后，直到程序员显式的释放它。 局部引用的生存期为创建后，直到程序员显式的释放他们，或在当前上下文（可以理解成Java程序调用Native代码的过程）结束之后没有被JVM发现有JAVA层引用而被JVM回收并释放。 弱全局引用的生存期为创建之后，到程序员显式的释放他们或JVM认为应该回收它的时候（比如内存紧张的时候）进行回收而被释放。
33	日志打印收集	日志必须有统一工具进行打印收集
34	使用高效序列化工具	FlatBuffer
35	配置属性，使用SP导致阻塞	SP数据不能太大，分开到不同XML。建议使用MMKV，datastore
36	JUC的加锁容器，不是万全的	这些只是对象函数是线程安全，但容器本容易被其他线程操作
37	参数或成员变量的类泛化程度	入参是context，但函数却要强制转换为activity，应该直接定义为activity
38	对象复用	如Android的Message 使用obtain获取对象，不是一味new Message
39	序列化控制	transient关键字，不需要序列化的属性前添加
40	数据容器的结合场景使用	如查询多的使用Arraylist或Vector，增删多的使用LinkedList，
41	键值对容器	取名把key -value 体现在 名字上
42	equal 和hashcode	修改判断，必须修改hashcode实现
43	Arrays.asList()把数组转换成lis 时，不能使用其修改集合相关的方	尤其和java.util.list不是一个类