几个友好Java代码习惯建议

我工作多年，个友惯建遇到过各种各样的码习同事。我见过各种代码，个友惯建优秀的码习、垃圾的个友惯建、没有吸引力的码习等等，所以这篇文章记录了一个优秀的个友惯建Java开发应该具备哪些良好的开发习惯或最佳实践。

1、码习封装方法参数

当你的个友惯建方法参数过多时，建议封装一个对象。码习下面是个友惯建反面教材，谁教你写成这样的码习代码？

public void updateX(long num, String str1, String str2, String str3, String str4, String str5, String str6) { }

尽量把这些输出封装到一个对象中。

public class X { private Long num; private String str1; ...}

为什么要这样写？个友惯建例如，您的码习方法用于查询。如果以后添加查询条件，个友惯建需要修改方法吗？每次添加时必须更改方法参数列表。封装一个对象，以后无论添加多少查询条件，只需要给对象添加字段即可。关键是代码看起来也很舒服！

2、封装业务逻辑

如果你看过“狗屎山”，你会有很深的亿华云计算感受。这样的方法可以写几千行代码，没有什么规则可言。经常负责人会说，这个业务太复杂了，没办法改进，是偷懒的借口。无论业务多么复杂，我们都可以通过合理的设计和封装来提高代码的可读性。下面是一个建议的代码。

@Transactionalpublic void clearBills(Long customerId) { //获取清算所需的票据ng ClearContext context = getClearContext(customerId); // 验证该金额是否合法 checkAmount(context); // 确定优惠券是否可用，并返回可扣除金额 CouponDeductibleResponse deductibleResponse = couponDeducted(context); // 结清所有账单 DepositClearResponse response = clearBills(context); // 发送还款对账消息 repaymentService.sendVerifyBillMessage(customerId, context.getDeposit()); // 更新帐户余额 accountService.clear(context, response); // 处理已清算的息票，用完或未绑定 couponService.clear(deductibleResponse); // 保存优惠券扣减记录 clearCouponDeductService.add(context, deductibleResponse);}

这段代码中的业务非常复杂。估计内部保守做了一万件事情，但是不同层次的人写的东西完全不一样。不得不赞这个业务的拆分，方法的高防服务器封装。大企业中有多个小企业。不同的业务可以调用不同的服务方法。

接手的人即使没有流程图等相关文件，也能快速了解业务。初级开发写的很多业务方法都是上一行代码给业务A，下一行代码给业务B，下一行代码给业务A。还有一堆单元逻辑嵌套在业务之间调用，这非常混乱并且有很多代码。

3、判断集合类型不为空的正确方法

很多人喜欢写这样的代码来判断集合。

if (list == null || list.size() == 0) { return null;}

当然，如果你坚持这样写是没有问题的。

org.springframework.util.CollectionUtils但是你不觉得不舒服吗，现在框架中的任何一个jar包都有一个收集工具类，比如com.baomidou.mybatisplus.core.toolkit.CollectionUtils. 以后请这样写。

if (CollectionUtils.isEmpty(list)) { return null;}

4、集合类型返回值不返回null

当你的业务方法返回一个集合类型时，请不要返回null，正确的服务器托管操作是返回一个空集合。看一下mybatis的列表查询。如果没有查询任何元素，它将返回一个空集合而不是 null。否则，调用者必须做NULL判断，大多数情况下对象也是如此。

5、推荐使用lombok

当然，这是一个有争议的问题，我的习惯是使用它来省略 getter、setter、toString 等。使用Lombok。

6、编写尽可能少的工具

为什么要少写一些工具类，因为你写的大部分工具类都包含在你引入的jar包中，比如String、Assert断言、IO上传文件、复制流、Bigdecimal]等等。编写自己的错误并加载冗余类很容易。

7、写有意义的方法注释

写这种注释是不是怕后来接手的人瞎了。

要么不要写它，要么只是在它之后添加一个描述。写这样的注释并从IDEA收到一堆警告很痛苦。

/*** 请求号码验证** @param a* @param b* @param param* @return Result*/

8、尽量不要让IDEA报警

很反感在IDEA代码窗口看到一连串的警告，很不舒服。因为有警告，说明代码可以优化，或者有问题。几天前，我在团队中发现了一个小错误。和我没有关系，只是同事们在外面看业务，判断业务为什么错了。我扫了一眼问题。

因为java中的整型字面量int是类型的，所以它们变成Integer了集合，然后点击它stepId就是一个long类型，而Long在集合中，那么这contains正确返回false了，它不是一个类型。

你看，如果你注意警告，你可以把鼠标移到上面看一下提示，就会少一个生产bug。

9、尽可能使用新的技术组件

我认为这是一个程序员应该具备的素质。反正我喜欢用新的技术部件，因为新技术组件的出现是解决老技术组件的不足，而作为技术人员，我们应该与时俱进。

当然，前提是做好准备，而不是想当然地升级。Java 17 已经发布了最简单的例子，新项目仍然使用Date来处理 DateTime。