【Java后台开发规范】--- 不简单的命名

前言

做Java开发的，大多数可能都有看过阿里的Java后台开发手册，里面有关于Java后台开发规范的一些内容，基本覆盖了一些通用、普适的规范，但大多数都讲的比较简洁，本文主要会用更多的案例来对一些规范进行解释，以及结合自己的经验做补充！

其他类型的规范

【Java后台开发规范】— 日志的输出
【Java后台开发规范】— 长函数、长参数
【Java后台开发规范】— 线程与并发
【Java后台开发规范】— 圈复杂度
【Java后台开发规范】— 设计原则
【Java后台开发规范】— Null值处理
【Java后台开发规范】— 异常的处理

命名

大家都是有经验的开发了，一些特别基本的命名规范还是了解的，比如驼峰、常量大写用下划线分割等等，所以我这里说的命名主要是强调如何才能做到见名知意，让命名更加有意义，让命名能让开发甚至业务一眼就能看懂，当然这还需要理解统一词汇的重要性。

含糊不清

有意义的命名

我们看如下一段方法，想要完成的行为就是把订单更新为充电中

无法直接从方法名理解方法意图

public void dealOrder(long orderId){
    Order order = orderMapper.getOrderById();
    order.setStatus(OrderStatus.CHARGING);
    orderMapper.update(order);
}

有具体目的了

public void dealOrderStatus(long orderId){
    Order order = orderMapper.getOrderById();
    order.setStatus(OrderStatus.CHARGING);
    orderMapper.update(order);
}

从业务含义出发

public void startCharging(long orderId){
    Order order = orderMapper.getOrderById();
    order.setStatus(OrderStatus.CHARGING);
    orderMapper.update(order);
}

魔法数值

// 魔法数值
ThreadUtils.sleep(5000);
// 定义有意义的名称
public static final long FIVE_SECOND = 5 * 1000;
ThreadUtils.sleep(FIVE_SECOND);

名不符实

两个方法的含义模糊不清，混在一起更无法区分，更重要的是方法名与方法内实际做的事不相符。

调整前

public static void main(String args[]){
    recharge();
}

public void recharge(){
	check();
    init();
    start();
}

public void start(){
    // 业务逻辑
}

调整后

public static void main(String args[]){
    rechargePrepare();
    startRecharge();
}

public void rechargePrepare(){
	check();
    init();
}

public void startRecharge(){
    // 业务逻辑
}

差不多的含义

public Order queryOrderInfo();
public Order queryOrderData();
public Order queryOrderList();

public Order getOrderData();
public Order getOrderInfo();
public Order getOrderList();

多此一举

double amountMoney;// 直接命名成double money
double incomeAmount;// 直接命名成double income

随意的简化命名

我们知道命名不宜过长，所以我们习惯用简写，我也认为在足矣表达其含义的情况下，命名越短越好，所谓言简意赅，但我们往往容易忽略上下文环境，随意的简化命名，从而带来不好可读性。

简写一般不具备业务含义

Document doc;
Response resp;
Request req;
Number num;
Second sec;

含有业务含义时，请注意简写的使用

CacheKey ck;
Object obj ---> Object className;
String str ---> String userName;
double d ---> double amount;

命名统一

这是一个非常简单的道理，统一规约是非常重要的，它能够提高代码的可读性，可维护性，减少人员的沟通成本，减少一些不必要的麻烦。

下面这些命名不存在谁对谁错，问题在于统一，saveOrder或者insterOrder都可以，保持一致就行，根据关键字联想最郁闷的就是不知道关键字。

saveOrder、deleteOrder、updateOrder、queryOrder
insterOrder、clearOrder、modifyOrder、selectOrder

类的命名

工具类：XxxUtils

抽象类：AbstractXXX、BaseXXX

工厂类：XxxFactory

异常类：XxxException

枚举类：XxxEnum

领域模型：DO、DTO、VO、DAO

设计模式：使用对应的设计模式为后缀，XxxBuilder、XxxFactory、XxxStrategy

测试类：XxxTest

头疼的英语

没办法，起个中文名都难，更何况是英语，这可能是很多人都曾遇到过的窘境，的确，有些需求描述让我们不太容易直接翻译成英文，更何况如果是英文不好的情况下，可能更麻烦。。。

这方面我建议可以多阅读一些优秀的源码，看看他们的命名习惯，也可以在github上找一些优秀的代码看看，多参考国人写的代码，会显得更亲近。

当然，我相信，实在不知道要如何翻译时，只能寻求翻译软件，但希望你能正确的区分应该使用动词还是名词。