前几天我在改一个老项目的代码。 本来只是加一个很小的判断结果一行代码让我卡了 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;getterpublic 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 秒。不是新同事不行是命名真的有问题。