Boolean 变量到底该怎么命名？

问题

假设你刚刚接手一个项目，然后看到了这样的代码

csharp 复制代码

public class OrderProcessor
{
    private bool open;
    private bool flag;
    private bool done;
    private bool status;
    
    public void Process(bool check)
    {
        if (open && flag)
        {
            flag = false;
            status = true;
        }
        
        if (done)
        {
            // 这里会发生什么？
        }
    }
}

鬼鬼！这段代码好读吗？

如果你觉得没有什么问题，这样，我问你几个问题：

open 到底表示什么？商店正在营业？文件已经打开？还是某个流程仍然开放？
flag 就更不用说了。这个名字几乎是在明晃晃地告诉后来的人："具体是什么意思，以后再说。"
至于 done，它表示"已经完成了吗"，还是在发出"把它标记为完成"的命令？

所有的变量名，单看名字，我们根本无法确定它们的意图。

含义模糊的 Boolean 变量就像埋在代码里的雷。平时看上去没什么问题，等到改 Bug 的时候、不得不在半夜排查代码的时候，才会发现自己根本不知道它想表达什么。

歧义很容易带来 Bug。

Review 时，审查者看到 if (done)，只能猜测开发的意图；后来的维护者看到 flag = false，也可能因为没有理解原来的逻辑，顺手把条件改反。

再看 if (!flag)：它是在打开某个功能，还是关闭某个功能？没人知道。

Boolean 变量的名字之所以重要，是因为它并不只是一个普通标签，更像是一个问题。代码提出问题，Boolean 值负责回答 true 或 false。

如果变量名本身不能构成一个清楚的问题，那么无论答案是"是"还是"否"，都没有多少意义。

四个锦囊

在绝大多数常见场景中，我们都可以从下面四个前缀开始考虑。它们不一定覆盖所有 Boolean 命名，但足以让大部分变量变成一句清楚、符合语法的问题。

1. is：身份与状态

当我们想描述某个对象当前是什么状态时，可以使用 is。它后面通常跟形容词。

推荐：isActive、isDeleted、isEmpty
不推荐：isAccess

isAccess 在语法上并不自然。如果要表达"拥有访问权限"，更合适的名字是 hasAccess。

2. has：拥有、包含与特征

当我们想表达某个对象是否拥有某项内容、是否包含某个元素，或者是否具备某种特征时，可以使用 has。它后面通常跟名词。

推荐：hasAccess、hasChildren、hasValidationErrors
不推荐：hasActive

active 描述的是状态，因此这里应该使用 isActive。

3. can：能力与权限

当我们想确认某个对象是否有能力、是否有权限执行某项操作时，可以使用 can。

推荐：canEdit、canDelete、canRetry
不推荐：canAdmin

canAdmin 的含义比较模糊。如果想表达用户的身份，可以使用 isAdmin；如果想表达用户是否可以执行管理操作，则可以使用 canAdminister。

4. should：意图与决策

当 Boolean 值表示一条业务规则，或者表示系统接下来是否应该执行某项操作时，可以使用 should。

它能把"我们能不能做"与"我们应不应该做"区分开来。

推荐：shouldRetry、shouldCacheResponse
不推荐：shouldUser

shouldUser 不是一个完整的问题。它想表达的是 shouldCreateUser，还是其他操作？只看名字无法判断。

这几个前缀一旦混用，例如写出 isAccess 或 hasActive，读者就不得不停下来，在脑子里重新组织一遍句子。阅读代码时的这种停顿，往往正是误解和 Bug 出现的地方。

前缀	适用场景	作用	示例
`is`	身份 / 状态	描述对象当前是什么或处于什么状态	`isActive`、`isEmpty`
`has`	拥有 / 包含	描述对象是否拥有某项内容或特征	`hasChildren`、`hasAccess`
`can`	能力 / 权限	描述对象是否能够执行某项操作	`canEdit`、`canRetry`
`should`	意图 / 业务逻辑	描述根据规则是否应该执行某项操作	`shouldCache`、`shouldRetry`

尽量避免否定式命名

Boolean 命名中还有一条非常实用的经验：尽量使用肯定形式，不要把否定直接写进变量名。

例如：

isNotEnabled
hasNoAccess
isDisabled

为什么要尽量避免这种写法？因为代码迟早可能需要判断它们的相反状态。

csharp 复制代码

if (!isDisabled)

看到这段代码，大脑需要先理解"已禁用"，然后再对它取反，最后才能得出"已启用"。这实际上是一种双重否定。

相比之下，下面的写法就直接得多：

csharp 复制代码

if (isEnabled)

否定形式在定义变量时可能很自然，甚至在某些代码流程中，会非常好用------"我现在就是要判断它有没有被禁用"。

但对于以后每一个阅读代码的人来说，它都可能带来额外的理解成本。

重构工具有时还会让问题变得更严重、更明显。

假设我们反转了一个 if 条件，IDE 又顺手把 isDisabled 改成 isNotDisabled，最终得到的名字只会更加难读。

不过，这条规则并不是说 isDisabled 在任何情况下都不能使用。

如果"禁用"本身就是业务领域中的明确状态，使用它也可能比生硬地创造一个反义词更准确。

真正应该避免的，是会频繁与 ! 组合、迫使读者反复计算双重否定的命名。

一个常见例外

如果程序需要映射外部 API，或者映射一个默认采用否定形式的 HTML 属性，例如 noValidate，那么保留外部名称通常是合理的。

即便如此，也应该尽量把这种命名限制在系统边界。在内部业务逻辑中，可以把它转换为肯定形式：

csharp 复制代码

bool shouldValidate = !request.noValidate;

别把属性命名规则直接套在方法参数上

前面的规则主要适合描述状态的属性或变量。但如果 Boolean 出现在方法参数中，仅仅把名字写清楚，往往还不够。

这就是常说的 Boolean Trap（Boolean 陷阱）：

csharp 复制代码

// 来自开源库的真实代码
schemaExport.Execute(false, true, false);

不用查看方法定义，你能立刻说出第二个 true 到底控制什么吗？显然不能。

你只能打开文档或者源码，重新确认每一个参数的含义。

当一个方法的签名接近 Execute(bool, bool, bool) 时，通常意味着它的 API 设计已经出现了问题。方法调用只剩下一串 true 和 false，参数原本想表达的业务含义全部消失了。

1. 拆分方法

如果 Boolean 参数会让方法执行完全不同的行为，那么可以直接拆成两个语义明确的方法。

csharp 复制代码

// 不推荐
email.Send(message, true); // true 是"立即发送"，还是"高优先级"？

// 推荐
email.SendImmediately(message);
email.SendQueued(message);

2. 使用 Enum

如果 Boolean 代表不同的执行模式，可以用 Enum 为每一种模式命名。

csharp 复制代码

// 不推荐
file.Write(data, true);

// 推荐
file.Write(data, WriteMode.Append);

3. 使用配置对象

如果方法需要接收多个开关，可以把它们收进一个配置对象。

csharp 复制代码

// 不推荐
export.Execute(false, true, false);

// 推荐
export.Execute(new ExportOptions { 
    Script = false, 
    Export = true, 
    JustDrop = false 
});

这样一来，每一个值控制什么都会直接显示在调用处，不必再靠参数位置猜测。

几种常见的反模式

如果准备整理项目中的 Boolean 命名，可以在 Code Review 时重点关注下面几类问题。

1. "随便起一个"的变量

flag、done、check 这类名字没有告诉读者：程序究竟在记录什么状态？

不推荐：if (check)
修改为：if (isPaymentVerified)

2. 前缀与语法不匹配

错误使用前缀会破坏变量原本应该表达的语义。

不推荐：if (user.hasActive)
修改为：if (user.isActive)

3. 双重否定

当 ! 与包含 Not、No 等否定含义的变量名同时出现时，通常都值得重新检查。

不推荐：if (!isNotEnabled)
修改为：if (isEnabled)

4. 身兼数职的 Boolean 变量

有些 Boolean 变量表面上只表示一个结果，背后却偷偷混合了多个条件。

例如：

不推荐：isValid

它实际上检查的是：用户存在、填写了邮箱，并且当前处于激活状态。

这时，与其使用含义宽泛的 isValid，不如直接把真正的业务含义写出来：

csharp 复制代码

bool isReadyForBilling = user.Exists && user.HasEmail && user.IsActive;

5. 不断改变含义的临时标记

还有一种常见写法，是在不同的逻辑阶段反复使用同一个局部 Boolean 变量。

csharp 复制代码

bool error = false;
if (!Save()) error = true;
if (!error && !SendEmail()) error = true;
return error;

这里的 error 就像一个被反复使用的桶：保存失败往里扔，发送邮件失败也往里扔。随着流程继续增长，它的含义只会越来越模糊。

更合适的做法是使用 Result 对象，或者在失败时直接提前返回，而不是反复回收同一个 Boolean 变量。

总结

命名不只是代码风格问题，它还决定了后来的人需要付出多少成本，才能理解这段代码。

当你把一个 Boolean 变量命名为 flag 时，你只是让自己在写代码的那一刻省了一点时间。

而当你把它命名为 isProcessed 时，你是在照顾那个六个月后不得不回来修复 Bug 的人。

当然，那个人很可能就是未来的你。