读-秦小波-编写高质量代码:改善java程序的151个建议

最新推荐文章于 2023-08-14 16:28:12 发布

熊猫小牛牛

最新推荐文章于 2023-08-14 16:28:12 发布

阅读量3.6k

点赞数 2

分类专栏：读书笔记

本文链接：https://blog.csdn.net/xiaoxufox/article/details/53747870

版权

读书笔记专栏收录该内容

10 篇文章 2 订阅

订阅专栏

有些建议不太用到，但是用到的时候如果不注意就会进坑，所以书名改成java的151个坑更合适。

不要在常量和变量中出现易混淆的字母
- 包名全小写，类名首字母全大写，常量全大写下划线分割，变量驼峰；
- 字母l作为长整形标志大写L；
莫让常量蜕变成变量
- 常量final staic，一般不会，主要是值常量的值不要通过计算获取值，值应该在编译期确认，不要在运行期更改；
三元操作符的类型务必一致
– 不一致会做转换，不管怎么转换，保持一致就行；
避免带有变长参数的方法重载
- 重载的话，调用时不一定是你想要那个方法；
别让null值和空值威胁到变长方法
- 直接传递null或空值会让编译器区分不了调用的是哪个变长方法；
覆写变长方法也循规蹈矩
- 覆写满足的条件：
  - 不能缩小访问权限；
  - 参数列表与重写方法相同(类型、数量、显示形式)；
  - 返回类型相同或是其子类；
  - 不能抛出新的异常或超出父类范围的异常，可以缩小或者不抛；
- 覆写变长方法参数列表必须完全一致；
警惕自增的陷阱
- java中count = count++等价于mockAdd(int count){int temp=count; count=count+1;return temp;};
- c++中count=count++会自增；
不要让旧语法困扰你
- 主要是java保有的一些关键字，如goto；
- 抛弃不用；
少用静态导入
- 不使用*通配符导入；
- 方法名是否具有明确清晰的意义；
- 感觉就是导入的常量类和常量一定要具有含义清晰，不能混淆；
不要在本类中覆盖静态导入的变量和方法
养成良好习惯，显示声明UID
- 实现Serializable接口的类，serialVersionUID要生成；
避免用序列化类在构造函数中为不变量赋值
- 序列化类中，不使用构造函数为final变量赋值；
- 基本类型，数组或简单对象（不通过new）；
避免为final变量复杂赋值
- 反序列化时final变量在以下情况下不会被重新赋值：
  - 通过构造函数赋值；
  - 通过方法返回值赋值；
  - final修饰的属性不是基本类型；
使用序列化类的私有方法巧妙解决部分属性持久化问题
- defaultWriteObject(),defaultReadObject(),writeXX和readXX屏蔽某些字段的序列化；
- 不要这个，基本不会用到；
break万万不可忘
易变业务使用脚本语言编写
- 之前工作中有个这样的需求，10几种类型根据公式计算不同生失效时间，公式易变，当时想用js，找了好久都没找到好用的，后来放弃了；
- 如果能找到适合的脚本engine，那就用吧；
慎用动态编译
避免instanceof非预期结果
- instanceof只能用于对象的判断，基本类型不行；
- 左操作数为null，直接返回false；
断言绝对不是鸡肋
- 在spring源码中n多使用断言的地方，感觉只是辅助注释的作用；
- 想用就用，不想用就算；
不要只替换一个类
- 如果你用ide的话，基本不会有这个问题；
- 发布时，禁止类文件替换，整体发布。常量类不要私自替换，因为常量会被预编译到引用的类中，会导致私自替换的不起作用；
用偶判断，不用奇判断
- 奇数判断，负数有问题
用整数类型处理货币
- 用什么整形，直接BigDecimal；
不要让类型默默转换
- 基本类型向包裹类型转换时，使用主动声明方式；
- long想Long转换：1L*X；
边界
- 单元测试时，边界测试要认真
四舍五入
- 第一次听说看见四舍五入还有这么多说法，服了，不过如果真有用到的地方一定要跟业务确认清楚；
- RoundingMode;
提防包装类型的null值
- 包装类型参入运算时，做null值校验；
谨慎包装类型的大小比较
- ==比较对象引用，>或<使用响应的value()方法;
- 使用相应的compareTo；
优先使用整形池
- valueOf生成的包装实例可以显著提供空间和时间性能；
- Integer和Long的会缓存-128到127之间的对象，范围外会new，Double和Float会new；
优先选择基本类型
- 基本类型可以先加宽，再转变成对应的包装类型，但是不能直接转变成宽的包装类型；
不要随机设置随机种子
- 随机数和种子的关系：
  - 种子不同，产生不同的随机数；
  - 种子相同，即使实例不同也产生相同的随机数；
- 非必要，不要设置种子；
接口中不要存在实现代码
静态变量一定要先声明后赋值
- 变量赋值分2步：先分配空间后赋值，如果先赋值后声明的话，就可能后声明的赋值覆盖之前的赋值；
不要覆写静态方法
- 实例对象有2个类型：
  - 表面类型：声明时的类型
  - 和实际类型，对象产生时的类型
- 非静态方法根据实际类型来执行；
- 静态方法一般是通过类名访问，也可以通过对象访问，当通过对象调用静态方法时，会通过对象的表面类型查找入口执行，又是一个第一次听说的东西；
构造函数尽量简化
避免在构造函数中初始化其他类
- 跟34对应，构造函数简化，然后提供其他初始化方法，spring中学会的；
使用构造代码块精炼程序
- 直接{}括起来的代码片段，会在每个构造函数中调用；
- 建议不要用；
构造代码块会想你所想
- 构造代码库在super，this调用的情况下也只会调用一次；
- 了解就行，非必要使用
使用静态内部类提供封装性
使用匿名类的构造函数
匿名类的构造函数很特殊
让多重继承称为现实
- 外部类继承一个，内部类再继承另一个；
让工具类不可实例化
- private 构造函数，阻止不了反射，实在不行就构造抛异常；
避免对象的浅拷贝
推荐使用序列化实现对象的拷贝
覆写equals方法时不要识别不出自己
- 对String做trim
- 这个要注意，好多接收外部数据什么的，都需要做trim处理；
equals应该考虑null值情景
- 判断null值情况
在equals中使用getClass进行类型判断
- 使用getClass进行类型判断，不要使用Instanceof，主要是防止继承情况下的判断；
- 这个还真没注意，下次要小心了；
覆写equals方法必须覆盖hashCode方法
推荐覆写toString方法
使用package-info类为包服务
- 很少用到，spring源码中看到，用这个给包做注释用的情况
- 作用：
  - 声明友好类和保内访问常量；
  - 为在包上标注注解提供便利；
  - 包注释说明；
不要主动进行垃圾回收
推荐使用String直接量赋值
- 常量池；
注意方法传递的参数要求
- replaceAll传递的第一参数是正则，我去，真没在意这个，下次小心；
正确使用String，StringBuffer、StringBuilder
- 一般情况String，频繁操作后面2个，单线程StringBuilder，线程安全StringBuffer；
注意字符串的位置
- 加号表达式中，String字符串具有最高优先级；
- 对于运算符优先级有疑问的，直接括号省事；
自由选择字符串拼接方法
- 加号，concat或append，耗时依次减少；
推荐在复杂字符串操作中使用正则表达式
强烈建议使用UTF编码
- 编码是开发永远的噩梦；
对字符串排序持一种宽容的心态
- Collator中文排序，gb2312差不多可以解决，复杂的就找开源的或自己实现吧；
性能考虑，数组是首选
- 性能要求高的场景中使用数组替代集合；
若有必要，使用变长数组
- 主要是初始定长，后期校验扩容
警惕数组的浅拷贝
- Arrays.copyOf产生的是一个浅拷贝，基本类型拷贝值，其他拷贝引用地址；
场景明确下，为集合指定初始容量
多种最值算法，适时选择
- 自己实现；
- 先排序，后取值：Arrays.sort();
避开基本类型数组转换list陷阱
- 基本类型不能泛型话；
- Arrays.asList()参数不能使用原始类型；
asList产生的list对象不可更改
- 产生的list是一个静态内部类；
不能的列表选择不同的遍历方法
- ArrayList实现RandomAcess随机存取接口，使用for循环更好，而不是foreach；
频繁插入和删除使用LinkedList
- 对比ArrayList，想想数据结构就明白了；
列表相等只需关心元素数据
- 在AbstractList中实现元素和长度比较
子列表只是原列表的一个视图
- subList返回子列表；
- 所有对subList产生对象的操作作用于原list；
推荐使用subList处理局部列表
生成子列表后不要再操作原列表
- 会异常；
使用Comparator排序
不推荐使用binarySerach对列表进行检索
- 二分查找建立在基本有序的情况才行；
- 实现RandomAccess或数据量小于5K进行二分查找，否则顺序查找；
集合中元素必须做到compareTo和equals方法
集合运算时使用更优雅的方式
- 并集addAll
- 交集retainAll
- 差集removeAll
使用suffle打乱列表
- collections.shuffle();
减少hashmap中元素的数量
- 主要是扩容的时候，可能会内部不够用；
集合中hash码不要重复
- 不重复最好，重复也无所谓，不用关心；
多线程使用Vector或hashTable
非稳定排序推荐使用List
- treeset适用于不变量的数据集合排序；
- 在处理过程中可能会重新排序的，可以使用list自行排序；
集合家族
- list
- set
- map
- queue
- 数组
- 工具类：Arrays和反射类Array，collections
- 扩展类：commons和google的collections
推荐使用枚举定义常量
- 不太喜欢这种；
使用构造函数协助描述枚举项
使用枚举常量时，小心switch带来的空值异常
在switch的default代码块中增加AssertionError错误
- 如果使用枚举做switch就不应该走到default；
枚举使用valueOf前必须进行校验
枚举实现工厂模式
枚举项的数量限制在64个以内
小心注解继承
- Inherit
枚举和注解结合使用威力更大
- 注解的值可以使用枚举来定义；
注意@Override不同版本的区别
- 1.5版本的接口实现，不需要override，1.6以上没问题，注意下就可以；
java的泛型是类型擦除的
- 泛型参数编译后会被清除；
不能初始化泛型参数和数组
- 类型擦除，无法获取具体参数
强制声明泛型的实际类型
不同场景使用不同的泛型通配符
- 读操作? extend限定泛型上界；
- 写操作? super限定泛型下界；
警惕泛型是不能协变和逆变的
- 协变：窄类型替换宽类型；
- 逆变：宽类型替换窄类型；
建议采用的顺序是List\List

if(!method.isAccessible()){
    method.setAccessible(true);
}

method.invoke(obj, args);

使用forName加载类文件
- 有个参数设置static方法是否调用，默认加载static代码块；
动态加载不适合数组
- 数组用的反射跟普通的不一样；
动态代码可以使代理模式更灵活
反射增加装饰模式的普适性
反射让模板方法模式更强大
不需要太多关注反射效率
- 如果有需求要用，就不要过分关注；
提倡异常封装
- 我们项目很少用，都是用封装errorcode，下次最起码保证自己的代码部分用到；

/** spring 中看到这种处理方式，感觉适合流程无关联性的业务*/
Class MyException extends Exception{
    private List<Throwable> causes = new ArrayList<Throwable>();

    public MyException(){
    }

    ...get set ...
}

采用异常链传递异常
- 异常需要封装和传递，不同视角展示不同提示；
受检异常尽可能转为非受检异常
不要在finally块中处理返回值return
- finally返回会覆盖try块中的return值；
- 屏蔽异常；
- 只做收尾；
不要在构造函数中抛出异常
- 这个还真没见过这样处理的；
使用Throwable获得栈信息
异常只为异常服务
- 还真这么干过，正常业务有问题，为了省事直接抛出异常处理；
多使用异常，性能问题放一边
不推荐覆写start方法
- 不覆写Thread类的start方法
启动线程前stop方法是不可靠的
不适用stop方法停止线程
线程优先级只是用3个等级
- 差距大，才有体现；
使用线程异常处理器提升系统可靠性

123.volatile不能保证数据同步

异步运算考虑使用callable接口
- 有返回值和异常处理；
优先选择线程池
选择不同的线程池
Lock和synchronized是不一样的
预防死锁
适当设置队列长度
- 阻塞队列的长度是固定的；
countDownLatch协调子线程
- CountDownLatch、CyclicBarrier和Semaphore区别;
CyclicBarrier让多线程齐步走
- 让多线程同时做某些事；
提升Java性能的基本方法
- 不要在循环条件中计算；
- 尽可能把变量、方法声明为final static类型；
- 缩小变量的作用范围；
- 频繁字符串操作使用StringBuffer或StringBuilder；
- 使用非线性检索；
- 覆写Exception的fillInStackTrace方法，耗时，看情况，没太多必要；
- 不建立冗余对象；
若非必要，不要克隆对象
- new做了优化；
推荐使用”望闻问切”的方式诊断性能
- 望：观察现象；
- 闻：团队的技术能力、氛围，习惯、擅长；
- 问：讨论；
- 切：分析问题；
定义性能衡量标准
解决首要系统性能问题
调整jvm参数提升性能
- JVM调优总结 -Xms -Xmx -Xmn -Xss;
性能是个大“咕咚”
- 没有慢的系统，只有不满足业务的系统；
- 没有慢的系统，只有架构不良的系统；
- 没有慢的系统，只有懒惰的技术人员；
- 没有慢的系统，只有不愿意投入的系统；
- 怀疑精神；
大胆采用开源工具
推荐使用Guava扩展工具包
- 看情况吧，有需要，可以用，没有需求，就拉倒吧；
Apache扩展包
推荐使用Joda日期时间扩展包
可以选择多种Collections扩展
提倡良好的代码风格
- 见过几百行代码的方法，看的疯了；
不要完全依靠单元测试来发现问题
- 单元测试不可能测试所有场景：
  - 正常场景；
  - 边界场景；
  - 异常场景；
- 单元测试没问题，可能全流程测试会出问题；
- 部分代码无测试，尤其是多线程环境的测试；
- 单元测试验证的是开发的想法，万一要是错的了，那不就挂了；
- 这个标题感觉改成不要相信测试最好，真实环境让你想吐；
让注释正确、清晰、简洁
让接口的职责保持单一
增强类的可替换性
依赖抽象而不是实现
抛弃7条不良的编码习惯
- 自由风格的代码；
- 不适用抽象的代码；
- 彰显个性的代码；
- 死代码；
- 冗余代码；
- 自以为是的代码；
- 见过最差的，日志居然用sysout打印，想骂人的感觉；
以技术员自律而不是工人
- 不为工作，爱你的工作；

总结：
1. 刚开始看，不像是国人写的，老外倒是喜欢写这种类型的书，感谢作者；
2. 泛型和注解部分写的不错；
3. 书中的坑，好多都是你用到时一不小心就进去了，所以用你不常用东西时，一定要先了解下，这是看这本书最重要的体会了；

熊猫小牛牛

关注

2
点赞
踩
13

收藏

觉得还不错? 一键收藏
2
评论
读-秦小波-编写高质量代码:改善java程序的151个建议

有些建议不太用到，但是用到的时候如果不注意就会进坑，所以书名改成java的151个坑更合适。不要在常量和变量中出现易混淆的字母包名全小写，类名首字母全大写，常量全大写下划线分割，变量驼峰；字母l作为长整形标志大写L；莫让常量蜕变成变量常量final staic，一般不会，主要是值常量的值不要通过计算获取值，值应该在编译期确认，不要在运行期更改；三元操作符的类型务必一致 – 不一致会做转换，
复制链接

扫一扫

专栏目录