Java 开发千万别给布尔变量加 is 前缀！很容易背锅
前几天我在改一个老项目的代码。 本来只是加一个很小的判断，结果一行代码让我卡了 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 秒。不是新同事不行，是命名真的有问题。