关于java:几个友好java代码编写习惯建议

3次阅读

共计 2361 个字符，预计需要花费 6 分钟才能阅读完成。

我工作多年，遇到过各种各样的共事。我见过各种代码，优良的、垃圾的、没有吸引力的等等，这篇文章记录集体的一些代码开发习惯。

当你的办法参数过多时，倡议封装一个对象。上面是反面教材，谁教你写成这样的代码？

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;
    ...
}

为什么要这样写？例如，您的办法用于查问。如果当前增加查问条件，须要批改办法吗？每次增加时必须更改办法参数列表。封装一个对象，当前无论增加多少查问条件，只须要给对象增加字段即可。要害是代码看起来也很难受！

如果你看过“狗屎山”，你会有很深的感触。这样的办法能够写几千行代码，没有什么规定可言。常常负责人会说，这个业务太简单了，没方法改良，是偷懒的借口。无论业务如许简单，咱们都能够通过正当的设计和封装来进步代码的可读性。上面是一个倡议的代码。

@Transactional
public 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。还有一堆单元逻辑嵌套在业务之间调用，这十分凌乱并且有很多代码。

很多人喜爱写这样的代码来判断汇合

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;}

当你的业务办法返回一个汇合类型时，请不要返回 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。
论断
以上是我集体的一些认识，如有不足之处请指出。

正文完