翻了一下我司某个微服务工程的代码，发现布尔变量的命名挺五花八门的。同一个文件里，有叫flag的，有叫success的，有叫normal的，有叫result的，还有叫warning和ignore的。各种风格混在一起。

这块我肯定是不管的，都是个人习惯而已，只不过呢，如果能命名的好一些，可以增强代码的可读性。

布尔变量和其他类型的变量不一样，它的值只有true和false两种，读代码的人看到它的时候，脑子里其实在期待一个回答：是还是不是。

所以布尔变量的名字，最好是能回答「是」或「否」。isActive在问「它是激活状态吗？」，hasChildren在问「它有子节点吗？」。读到if(isActive)的时候，脑子里会自动把它翻译成一个判断句，理解成本很低。

如果没有做到这一点，那么读代码的人就需要额外花心思去猜。flag在表达什么？normal是什么意思？result代表什么结果？这些名字单独拿出来看，你没法判断它在回答什么问题。

这个区分看起来不怎么起眼，但在一个几百行的方法里，布尔变量的名字清不清晰，直接影响你读代码的速度。

四个常用的前缀可以覆盖绝大多数场景

我们可以用四个英文前缀来给布尔变量命名，基本能覆盖日常开发中遇到的大多数场景。我这边的工程里的代码，有一部分已经是这么用的，只是没有刻意去统一。

is：描述状态和身份。后面跟形容词或过去分词，表示某个东西当前处于什么状态，比如：

//是否跨店支援 boolean isCrossSupportUser; //是否冻结 boolean isFreeze; //申请单是否已下推 boolean isPushed;

读到这些名字，脑子里立刻就能翻译成一个判断句，不需要去看上下文就知道它在问什么。

has：描述拥有和包含。后面跟名词，表示某个对象是否具备某个属性或子元素。

//是否有操作权限 boolean hasSchedulePermission; //是否有历史数据权限 boolean hasHistoryPermission;

can：描述能力和权限。表示某个对象是否被允许执行某个动作。在权限判断场景下特别好用。比如判断当前用户能否编辑某个资源，canEdit比isEditable更准确地表达了「权限」这层含义。isEditable可能被理解成「这个资源本身是可编辑的」，而canEdit明确在说「当前操作者有权限编辑它」。

should：描述业务意图。表示系统是否应该执行某个操作，通常和业务规则有关：

//是否应该跳过定时任务 boolean shouldSkipScheduledTask;

这个名字不是在描述一个状态，也不是在描述一个权限，而是在表达一个业务决策。用should前缀，把「系统该不该做这件事」和「系统能不能做这件事」区分开了。

四个前缀的适用场景，我们用一张表概括一下：

is和has容易搞混。一个判断方法是看后面跟的词性：跟形容词用is（isActive），跟名词用has（hasAccess）。如果写成了isAccess或者hasActive，读起来有点别扭。

几个容易踩的坑

前缀混搭

偶尔在代码里能看到is和can叠在一起用的情况，比如isCanSchedule。写的时候脑子里想的是「是否可以执行某个操作」，直接把中文翻译成了英文。但这两个前缀各管各的领域，is管状态，can管能力，叠在一起读起来反而不知道该按哪个理解。

类似的还有isOpenAutoBind，is和open语义重叠，保留一个就够了。

否定命名

有些场景下，写代码的人觉得用否定形式更自然。比如判断一个文件不是视频，写成isNotVideo；判断是否禁用某个校验，写成disableSyncStatusCheck。

问题在于，当你对一个否定命名的变量取反的时候，就出现了双重否定。if(!isNotVideo)在问什么？增加了理解的难度，换成if(isVideo)就好多了。

语义模糊

flag大概是布尔变量里最常见的模糊命名了。在我们对接某个低代码平台的Client类里，Boolean flag这个变量在同一个文件中出现了十几次，每次都是从接口响应里取一个success字段赋给它，然后if(flag==null||!flag)做判断。逻辑没问题，但flag这个名字完全没有携带信息量。

方法参数里的布尔陷阱

布尔变量作为类的属性或方法的局部变量时，有变量名做上下文，可读性通常还行。但作为方法参数传进去的时候，问题会被放大。

工程里某个模块的Repository层有一组方法，参数列表里都有一个boolean fully，控制是否加载完整的关联数据。调用的地方长这样：

//不熟悉的同事看到这里的true，完全不知道它在控制什么 repository.getById(planId,true);

不打开方法签名看，没人知道这个true是什么意思。这个问题在业界有个专门的名字叫「布尔陷阱」，指的是调用方传了一个布尔值，但读调用代码的人完全无法从这个true或false推断出它的含义。

几种常见的改善方式：

如果布尔参数控制的是两种截然不同的行为，考虑拆成两个方法。比如send(message,true)和send(message,false)，不如拆成sendImmediately(message)和sendQueued(message)。

如果布尔参数代表的是一种模式选择，用枚举替代。file.write(data,true)不如file.write(data,WriteMode.APPEND)来得直观。

如果方法有多个布尔参数，用配置对象包装。把execute(false,true,false)换成传入一个ExecuteOptions对象，每个选项都是一个有名字的字段。

小结

is、has、can、should四个前缀用熟了，日常开发中的布尔命名基本就够用了。偶尔碰到不知道该用哪个前缀的情况，大概率是这个布尔变量承载了太多含义，该拆开来了。