Go 布尔变量命名：用状态、能力和决策替代 flag

原作者：Christopher Johnson。原文：Stop Naming Your Variables "Flag": The Art of Boolean Prefixes。
原文仅作为主题与观点参考，本文不是逐段翻译。正文按 Go 的语言习惯重新组织结构、论证与示例，并补充布尔参数、领域状态和 code review 中的实际边界。

布尔值只有两种取值，但布尔变量有时比字符串或数字更难理解。问题通常不在类型，而在名字：flag、done、status 和 check 只说明这里有一个开关，没有说明开关控制什么。

flag := false

if !flag {
	// What condition is being checked?
}

读到这段代码时，无法判断 false 表示未完成、不可用、未验证，还是暂时关闭。维护者只能继续追踪赋值位置，再从控制流里猜测含义。

布尔变量适合写成一个能用「是」或「否」回答的问题。isPaymentVerified 问的是付款是否已经验证，canRetry 问的是当前操作能否重试。条件语句因此接近自然语言，读者不必先翻译变量名。

四类前缀分别表达什么

多数布尔值可以从 is、has、can、should 开始命名。这四类前缀分别表达状态、持有关系、能力和决策。

前缀	表达的含义	示例
`is`	对象当前是什么状态	`isActive`、`isEmpty`、`isArchived`
`has`	对象是否持有某项数据、关系或特征	`hasAccess`、`hasChildren`、`hasErrors`
`can`	当前主体是否具备执行动作的能力或权限	`canEdit`、`canDelete`、`canRetry`
`should`	根据规则得出的意图或下一步决策	`shouldRetry`、`shouldNotify`、`shouldCache`

这些前缀还会约束后面的词。is 通常连接形容词或状态，例如 isActive；has 后面通常是名词，例如 hasAccess；can 和 should 后面通常是动作，例如 canEdit 和 shouldRetry。

isAccess、hasActive、canAdmin 之所以别扭，是因为它们没有组成完整的问题。改成 hasAccess、isActive、canAdminister 后，调用处不再需要额外解释。

这套前缀是语义检查方法，不是 Go 的强制命名规则。作用域很短、含义已经由语言惯例确定的返回值，使用 ok、found 或测试里的 wantErr 往往更自然。exported field 也可以写成 Enabled bool，不必为了套规则改成 IsEnabled bool。名称需要结合 type、package 和返回位置理解，前缀只在确实增加信息时保留。

`is` 描述事实，`should` 表达决策

状态和决策经常被混在同一个变量里。假设任务执行失败后，系统需要判断是否重试：

_, isRetryable := retryableErrors[errCode]
hasAttemptsRemaining := attempt < maxAttempts
shouldRetry := isRetryable && hasAttemptsRemaining

isRetryable 描述错误本身的性质，hasAttemptsRemaining 描述当前上下文，shouldRetry 则是业务规则计算出的决定。这三个名字把事实与策略分开了。后续即使加入退避时间、幂等要求或人工拦截，shouldRetry 仍然可以作为稳定的决策边界。

同样，canDelete 更适合表示权限和系统能力，shouldDelete 则表示规则建议执行删除。一个用户可能有删除权限，但当前记录处于审计保留期，最终仍然不应该删除。把二者都叫作 deleteFlag，这层差异就消失了。

优先使用正向名称，但不要机械改写领域状态

负向名称容易在调用处形成双重否定：

if !isNotEnabled {
	startJob()
}

如果变量表达的确实是「可用」，直接写成 isEnabled 更容易理解。hasNoAccess 也通常可以改成 hasAccess，让否定只出现在条件表达式的一处。

if isEnabled && hasAccess {
	startJob()
}

不过，正向命名不是把所有 Disabled、Deleted 或 Missing 都反转。isDeleted 可能对应数据库中的删除状态，isDisabled 可能对应账号管理里的明确业务动作，isMissing 也可能是解析结果的一种合法分类。强行改成 isNotDeleted 或语义并不等价的 isActive，反而会隐藏领域事实。

更实用的判断标准是：变量是否使用领域里的真实词汇，条件语句是否产生双重否定，反转后是否仍然表达同一个概念。外部 API 的 noValidate 这类负向字段可以留在传输边界，进入领域逻辑后再映射成 shouldValidate := !request.NoValidate。

布尔参数会在调用处丢失含义

属性名在条件表达式里仍然可见，位置参数却只剩下 true 和 false：

exportReport(data, false, true, false)

调用者无法从这行代码判断三个值分别控制脚本生成、文件覆盖还是压缩。即使函数签名里的参数名写得很好，代码评审者阅读调用处时仍然要跳转到定义。

当布尔值会明显改变函数行为时，可以把行为拆成不同方法：

mailer.SendImmediately(ctx, message)
mailer.Enqueue(ctx, message)

当参数表示有限模式时，用自定义 type 和常量：

type WriteMode int

const (
	WriteTruncate WriteMode = iota
	WriteAppend
)

writeFile(data, WriteAppend)

多个选项适合收进配置 struct：

type ExportOptions struct {
	IncludeScript     bool
	OverwriteExisting bool
	CompressOutput    bool
}

exportReport(data, ExportOptions{
	IncludeScript:     false,
	OverwriteExisting: true,
	CompressOutput:    false,
})

具名选项不是越多越好。如果两个模式代表完全不同的业务动作，拆分方法通常比继续扩展配置 struct 更清楚。Martin Fowler 将这种通过布尔参数切换行为的设计称为 Flag Argument，并建议调用方优先使用能直接表达意图的接口。

复合条件应当命名为业务结论

isValid 看似清楚，但它实际包含多项规则。用户记录存在、邮箱已填写、账号状态正常、付款资料完整，任何一项变化都可能改变 valid 的含义。

isReadyForBilling := user.Exists() &&
	user.HasEmail() &&
	user.IsActive() &&
	paymentProfile.IsComplete()

isReadyForBilling 没有逐项复述条件，而是说明这些条件共同支持什么业务结论。条件增加时，调用处仍然在问同一个问题。

这种命名也适合提取复杂条件。与其让多个分支重复一长串判断，不如把规则放进 isReadyForBilling() 或 shouldCreateInvoice()。如果它们是 exported method，则按照 Go 的大小写规则写成 IsReadyForBilling() 和 ShouldCreateInvoice()。函数名表达意图，函数体保存细节，测试也可以围绕业务结论组织。

不要让一个布尔值在流程中不断变义

另一类常见问题是把布尔变量当作临时容器：

hasError := false

if err := saveOrder(ctx); err != nil {
	hasError = true
}
if !hasError {
	if err := sendReceipt(ctx); err != nil {
		hasError = true
	}
}

return hasError

这里的 hasError 一会儿表示保存失败，一会儿又表示发送失败，返回值还是 true 代表失败。继续增加步骤后，控制流会越来越难确认。

Go 代码更适合直接返回带上下文的 error。如果调用方只关心成功与否，也应该把错误压缩成布尔值的动作放在边界上。布尔值适合回答一个稳定问题，不适合充当多个阶段共用的错误标记。

if err := saveOrder(ctx); err != nil {
	return fmt.Errorf("save order: %w", err)
}
if err := sendReceipt(ctx); err != nil {
	return fmt.Errorf("send receipt: %w", err)
}

return nil

Code review：检查布尔问题是否完整

看到布尔值时，可以直接把变量名代入条件语句朗读一遍：

if isPaymentVerified 能否形成明确问题；
if !isNotEnabled 是否出现双重否定；
canEdit 与 shouldEdit 是否混淆能力和决策；
isValid 是否掩盖了更具体的业务结论；
函数调用里的裸 true、false 是否改变了主要行为；
同一个局部变量是否在流程中承担了不同含义。

Go 自身的命名习惯同样强调上下文。Effective Go 要求使用 MixedCaps，并以 Owner() 而不是 GetOwner() 为例说明多余前缀应该删除。Google Go Style Guide 也提醒 exported symbol 会和 package 名一起出现，命名时应减少重复。布尔前缀是否保留，应看它能否帮助调用处组成一个清楚的问题。