大家好，我是大华。
前几天我在改一个老项目的代码。 本来只是加一个很小的判断，结果一行代码让我卡了 10 分钟。
if (user.isDeleted()) {
// ...
}
我心里想：deleted？是已经被删了，还是要不要删除？
于是我顺手点进了 User 类。
private Boolean isDeleted;
再往下翻方法的时候，我发现有的地方在用：
user.isDeleted()
有的地方却在用：
user.getIsDeleted()
这时候问题就来了，到底哪个才是规范写法？
那布尔类型的变量，到底要不要加 is 前缀？
一、入门级的写法
如果你是刚接触 Java 不久，十有八九会这样写：
private boolean isSuccess;
private boolean isDeleted;
private boolean isEnable;
原因很简单：
- 布尔值只有
true / false - 加个
is，一看就知道是不是
逻辑上完全没问题，而且 IDE、编译器也不会报错。
那问题到底出在哪？
二、场景
我给你还原一个开发中的场景。
1️⃣ 定义阶段：一切都很合理
private boolean isDeleted;
语义清晰：是否已删除，没毛病。
2️⃣ 生成 getter / setter
用 IDE 回车，生成 getter / setter
结果生成了这些方法：
你发现了吗？
- getter 叫
getDeleted() - setter 叫
setDeleted() - 字段却是
isDeleted
已经开始不统一了。
3️⃣ 一旦字段是 Boolean（不是 boolean）
代码会变得更神奇。
private Boolean isDeleted;
有些 IDE 会生成：
public Boolean getIsDeleted() { ... }
public void setIsDeleted(Boolean isDeleted) { ... }
于是项目里开始出现三种名字：
- isDeleted（字段）
- isDeleted()（方法）
- getIsDeleted()（方法）
这时候你再接上 MyBatis / Jackson / Swagger / Lombok，乐子就来了。
三、为什么框架不喜欢 is 前缀？
1️⃣ Java Bean 规范，本身就有点偏执
在 Java Bean 规范里：
- boolean 类型的 getter，可以是
isXxx() - 但 Xxx 本身不应该再带 is
规范推荐的是：
private boolean deleted;
public boolean isDeleted() { ... }
而不是：
private boolean isDeleted;
public boolean isIsDeleted() { ... }
虽然 IDE 会帮你兜底，但规范层面就是反着来的。
2️⃣ JSON 映射时，名字会偷偷变
看一个常见例子：
private boolean isDeleted;
用 Jackson 转 JSON，结果可能是：
{
"deleted": true
}
也可能是：
{
"isDeleted": true
}
取决于：字段、getter 名、注解和Jackson 版本
同一个字段，在不同项目里表现不一样。
这不是 bug，这是规范 + 约定 + 实现差异的组合。
3️⃣ 数据库字段更尴尬
数据库里你一般会这样建字段：
is_deleted tinyint(1)
Java 里你写：
private Boolean isDeleted;
ORM 映射时：
- 有人映射
is_deleted → isDeleted - 有人映射
is_deleted → deleted
团队里如果没有统一约定，很快容易会乱。
四、is 会让语义变模糊
这是我个人觉得最致命的一点。
来看这几个变量名：
isDeleted
isEnable
isSuccess
isUsed
你仔细想一想：
isDeleted = true：已删除？还是需要删除？isEnable = false：当前不可用？还是不允许启用？isSuccess = false：操作失败？还是还没执行？
is 很容易让状态和动作意图混在一起。
而如果换成这样：
deleted
enabled
success
used
搭配方法：
if (user.isDeleted()) { ... }
if (!account.isEnabled()) { ... }
语义反而更自然。
五、推荐的写法
布尔命名，其实可以分三类。
1、表示状态的
这种是最标准、最推荐的写法。
private boolean deleted;
private boolean enabled;
private boolean active;
private boolean locked;
对应方法：
public boolean isDeleted() { ... }
public boolean isEnabled() { ... }
特点：
- 字段是“状态”
- getter 用
isXxx() - 读起来像一句自然语言
比如：
if (user.isDeleted())
翻译成中文就是：用户是删除状态吗？非常顺。
2、表示是否拥有的用 has 前缀
有些布尔值表达的不是状态，而是是否拥有某种东西。
比如：
private boolean hasPermission;
private boolean hasChildren;
private boolean hasLogin;
getter：
public boolean hasPermission() { ... }
public boolean hasChildren() { ... }
这种语义就更自然：
if (user.hasPermission())
读起来就是：用户有没有权限？
比：
if (user.isHasPermission())
自然太多了。
3、表示能力的用 can 前缀
如果表达的是能不能做某件事，用 can 也比 is 更清晰。
private boolean canEdit;
private boolean canDelete;
private boolean canExport;
使用：
if (user.canDelete())
这时候它表达的不是状态，而是能力判断。
和：
if (user.isDelete())
完全不是一个层级的语义。
六、不推荐的写法
private boolean isDeleted;
private Boolean isEnable;
private boolean isHasPermission;
private boolean isCanEdit;
问题在于：
- 语义重复
- getter 容易变成奇怪形式
- 框架解析可能不一致
- 可读性下降
尤其是：
isHasPermission
isCanEdit
读起来非常的拧巴。
七、之前经历
以前一个项目里，有两个字段：
private Boolean isValid;
private Boolean valid;
一个是历史字段，一个是新字段。
代码里经常出现：
if (user.isValid()) { ... }
if (user.getIsValid()) { ... }
新来的同事问我：这两个有什么区别？
我当场沉默了 3 秒。不是新同事不行，是命名真的有问题。
本文首发于公众号：程序员大华，专注前端、Java开发，AI应用和工具的分享。关注我，少走弯路，一起进步！
