改善Java程序的151个建议

Java开发中通用的方法和准则

建议1:不要在常量和变量中出现易混淆的字母

建议2:莫让常量蜕变成变量

建议3:三元操作符的类型务必一致

建议4:避免带有变长参数的方法重载

建议5:别让null值和空值威胁到变长方法

建议6:覆写变长方法也循规蹈矩

建议7:警惕自增的陷阱

建议8:不要让旧语法困扰你

建议9:少用静态导入

建议10:不要在本类中覆盖静态导入的变量和方法

建议11:养成良好习惯,显式声明UID

建议12:避免用序列化类在构造函数中为不变量赋值

建议13:避免为final变量复杂赋值

建议14:使用序列化类的私有方法巧妙解决部分属性持久化问题

建议15:break万万不可忘

建议16:易变业务使用脚本语言编写

建议17:慎用动态编译

建议18:避免instanceof非预期结果

建议19:断言绝对不是鸡肋

建议20:不要只替换一个类

基本类型

建议21:用偶判断,不用奇判断

建议22:用整数类型处理货币

建议23:不要让类型默默转换

建议24:边界,边界,还是边界

建议25:不要让四舍五入亏了一方

建议26:提防包装类型的null值

建议27:谨慎包装类型的大小比较

建议28:优先使用整型池

建议29:优先选择基本类型

建议30:不要随便设置随机种子

类、对象及方法

建议31:在接口中不要存在实现代码

建议32:静态变量一定要先声明后赋值

建议33:不要覆写静态方法

建议34:构造函数尽量简化

建议35:避免在构造函数中初始化其他类

建议36:使用构造代码块精炼程序

建议37:构造代码块会想你所想

建议38:使用静态内部类提高封装性

建议39:使用匿名类的构造函数

建议40:匿名类的构造函数很特殊

建议41:让多重继承成为现实

建议42:让工具类不可实例化

建议43:避免对象的浅拷贝

建议44:推荐使用序列化实现对象的拷贝

建议45:覆写equals方法时不要识别不出自己

建议46:equals应该考虑null值情景

建议47:在equals中使用getClass进行类型判断

建议48:覆写equals方法必须覆写hashCode方法

建议49:推荐覆写toString方法

建议50:使用package-info类为包服务

建议51:不要主动进行垃圾回收

字符串

建议52:推荐使用String直接量赋值

建议53:注意方法中传递的参数要求

建议54:正确使用String、StringBuffer、StringBuilder

建议55:注意字符串的位置

建议56:自由选择字符串拼接方法

建议57:推荐在复杂字符串操作中使用正则表达式

建议58:强烈建议使用UTF编码

建议59:对字符串排序持一种宽容的心态

数组和集合

建议60:性能考虑,数组是首选

建议61:若有必要,使用变长数组

建议62:警惕数组的浅拷贝

建议63:在明确的场景下,为集合指定初始容量

建议64:多种最值算法,适时选择

建议65:避开基本类型数组转换列表陷阱

建议66:asList方法产生的List对象不可更改

建议67:不同的列表选择不同的遍历方法

建议68:频繁插入和删除时使用LinkedList

建议69:列表相等只需关心元素数据

建议70:子列表只是原列表的一个视图

建议71:推荐使用subList处理局部列表

建议72:生成子列表后不要再操作原列表

建议73:使用Comparator进行排序

建议74:不推荐使用binarySearch对列表进行检索

建议75:集合中的元素必须做到compareTo和equals同步

建议76:集合运算时使用更优雅的方式

建议77:使用shuffle打乱列表

建议78:减少HashMap中元素的数量

建议79:集合中的哈希码不要重复

建议80:多线程使用Vector或HashTable

建议81:非稳定排序推荐使用List

建议82:由点及面,一叶知秋—集合大家族,先找jdk实现

枚举和注解

建议83:推荐使用枚举定义常量

建议84:使用构造函数协助描述枚举项

建议85:小心switch带来的空值异常

建议86:在switch的default代码块中增加AssertionError错误

建议87:使用valueOf前必须进行校验

建议88:用枚举实现工厂方法模式更简洁

建议89:枚举项的数量限制在64个以内

建议90:小心注解继承

建议91:枚举和注解结合使用威力更大

建议92:注意@Override不同版本的区别

泛型和反射

建议93:Java的泛型是类型擦除的

建议94:不能初始化泛型参数和数组

建议95:强制声明泛型的实际类型

建议96:不同的场景使用不同的泛型通配符

建议97:警惕泛型是不能协变和逆变的

建议98:建议采用的顺序是List<T>、List<?>、List<Object>

建议99:严格限定泛型类型采用多重界限

建议100:数组的真实类型必须是泛型类型的子类型

建议101:注意Class类的特殊性

建议102:适时选择getDeclared×××和get×××

建议103:反射访问属性或方法时将Accessible设置为true

建议104:使用forName动态加载类文件

建议105:动态加载不适合数组

建议106:动态代理可以使代理模式更加灵活

建议107:使用反射增加装饰模式的普适性

建议108:反射让模板方法模式更强大

建议109:不需要太多关注反射效率

异常

建议110:提倡异常封装

建议111:采用异常链传递异常

建议112:受检异常尽可能转化为非受检异常

建议113:不要在finally块中处理返回值

建议114:不要在构造函数中抛出异常

建议115:使用Throwable获得栈信息

建议116:异常只为异常服务

建议117:多使用异常,把性能问题放一边

多线程和并发

建议118:不推荐覆写start方法

建议119:启动线程前stop方法是不可靠的

建议120:不使用stop方法停止线程

建议121:线程优先级只使用三个等级

建议122:使用线程异常处理器提升系统可靠性

建议123:volatile不能保证数据同步

建议124:异步运算考虑使用Callable接口

建议125:优先选择线程池

建议126:适时选择不同的线程池来实现

建议127:Lock与synchronized是不一样的

建议128:预防线程死锁

建议129:适当设置阻塞队列长度

建议130:使用CountDownLatch协调子线程

建议131:CyclicBarrier让多线程齐步走

性能和效率

建议132:提升Java性能的基本方法

建议133:若非必要,不要克隆对象

建议134:推荐使用“望闻问切”的方式诊断性能(性能表现,项目被动产生信息项目内部,和写的人沟通,看设计看日志看代码)

建议135:必须定义性能衡量标准

建议136:枪打出头鸟—解决首要系统性能问题

建议137:调整JVM参数以提升性能

建议138:性能是个大“咕咚”(某些Javaer一直在质疑Java系统的性能,于是我们自己也跟着怀疑Java的性能—这就是发生在我们身边的真实“咕咚”但是只有现实才是依据)

开源世界

建议139:大胆采用开源工具

建议140:推荐使用Guava扩展工具包

建议141:Apache扩展包

建议142:推荐使用Joda日期时间扩展包

建议143:可以选择多种Collections扩展

思想为源

建议144:提倡良好的代码风格

建议145:不要完全依靠单元测试来发现问题

建议146:让注释正确、清晰、简洁

建议147:让接口的职责保持单一

建议148:增强类的可替换性

建议149:依赖抽象而不是实现

建议150:抛弃7条不良的编码习惯
(自由格式的代码,不使用抽象的代码,彰显个性的代码,死代码,冗余代码,拒绝变化的代码,自以为是的代码)

建议151:以技术员自律而不是工人

更新时间:2020-02-18 16:43:59

本文由 寻非 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
原文链接:https://www.zhouning.group/archives/改善java程序的151个建议
最后更新:2020-02-18 16:43:59

评论

Your browser is out of date!

Update your browser to view this website correctly. Update my browser now

×