问题

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

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、isEmptyhas拥有 / 包含描述对象是否拥有某项内容或特征hasChildren、hasAccesscan能力 / 权限描述对象是否能够执行某项操作canEdit、canRetryshould意图 / 业务逻辑描述根据规则是否应该执行某项操作shouldCache、shouldRetry

尽量避免否定式命名

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

例如：

• isNotEnabled
• hasNoAccess
• isDisabled

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

if (!isDisabled)

看到这段代码，大脑需要先理解“已禁用”。

然后再对它取反，最后才能得出“已启用”。这实际上是一种双重否定。

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

if (isEnabled)

否定形式在定义变量时可能很自然，甚至在某些代码流程中会非常好用。

比如，“我现在就是要判断它有没有被禁用”。

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

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

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

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

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

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

一个常见例外

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

即便如此，也应该尽量把这种命名限制在系统边界。

在内部业务逻辑中，可以把它转换为肯定形式：

bool shouldValidate = !request.noValidate;

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

前面的规则主要适合描述状态的属性或变量。

但如果 Boolean 出现在方法参数中，仅仅把名字写清楚，往往还不够。

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

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

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

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

当一个方法的签名已经接近 Execute(bool, bool, bool) 这种样子时，往往说明它的 API 设计出了问题。

调用方最终面对的，只是一串 true 和 false。

原本想要表达的业务含义，也在这一连串布尔值里被冲淡了。

1. 拆分方法

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

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

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

2. 使用 Enum

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

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

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

3. 使用配置对象

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

// 不推荐
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，不如直接把真正的业务含义写出来：

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

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

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

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

这里的 error 就像一个被反复使用的桶：保存失败往里扔，发送邮件失败也往里扔。

随着流程继续增长，它的含义只会越来越模糊。

更合适的做法是使用 Result 对象，或者在失败时直接提前返回。

而不是反复回收同一个 Boolean 变量。

总结

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

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

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

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