好奇一下，程序员是怎么给布尔变量命名的?

翻了一下我司某个微服务工程的代码发现布尔变量的命名挺五花八门的。同一个文件里有叫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状态、身份后面跟形容词isActive、isPushedhas拥有、包含后面跟名词hasChildren、hasPermissioncan能力、权限描述能否做某事canEdit、canRetryshould业务意图描述该不该做某事shouldRetry、shouldCacheis和has容易搞混。一个判断方法是看后面跟的词性跟形容词用isisActive跟名词用hashasAccess。如果写成了isAccess或者hasActive读起来有点别扭。几个容易踩的坑前缀混搭偶尔在代码里能看到is和can叠在一起用的情况比如isCanSchedule。写的时候脑子里想的是「是否可以执行某个操作」直接把中文翻译成了英文。但这两个前缀各管各的领域is管状态can管能力叠在一起读起来反而不知道该按哪个理解。类似的还有isOpenAutoBindis和open语义重叠保留一个就够了。否定命名有些场景下写代码的人觉得用否定形式更自然。比如判断一个文件不是视频写成isNotVideo判断是否禁用某个校验写成disableSyncStatusCheck。问题在于当你对一个否定命名的变量取反的时候就出现了双重否定。if(!isNotVideo)在问什么增加了理解的难度换成if(isVideo)就好多了。语义模糊flag大概是布尔变量里最常见的模糊命名了。在我们对接某个低代码平台的Client类里Boolean flag这个变量在同一个文件中出现了十几次每次都是从接口响应里取一个success字段赋给它然后if(flagnull||!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四个前缀用熟了日常开发中的布尔命名基本就够用了。偶尔碰到不知道该用哪个前缀的情况大概率是这个布尔变量承载了太多含义该拆开来了。