Google C++每周贴士 #45: 少用Flags，尤其是在库代码中

（原文链接：https://abseil.io/tips/45 译者：clangpp@gmail.com）

每周贴士 #45: 少用Flags，尤其是在库代码中

• 最初发布于：2013-06-03
• 作者：Titus Winters
• 短链接：abseil.io/tips/45

“我真正想要的，是用不可静态预测的全局变量控制我代码的行为，其使用日志没有完全被记录，且移走它非常费劲。”——从来没有人

在产品代码中普遍使用flags，尤其是在库里面，是一个错误。如果不是真的必要，不要使用flags。就这样，勿谓言之不预也。

Flags是全局变量，而且只会更坏：仅读代码不肯能知道这个变量的值。一个flag可能不只是在启动的时候被赋值，而且可能晚些时候被以任意方式修改。如果你在你的二进制文件中跑了一个服务器，那么通常没法保证你的flag的值在不同的循环中保持不变，它被改动了也不会给你通知，你甚至没有任何办法查询这样的改动。

如果你的产品环境直接打印了每次二进制程序调用的日志，并且存储了这些日志，太棒了。大部分环境做不到。对于库代码，这种不确定性尤其可恶：你上哪儿知道要用的某个特性实际上嗝屁了？简单的答案是：你不知道。

Flags还让删除老代码变得富有挑战。在迁移到新的后端的过程中，你会 认为 删除遗留代码只不过是删除不需要的依赖关系，然后执行史上最幸福的git rm。那你可就错了。如果你的老程序定义了几百个flags，并且它们被产品代码引用了，那么简单地删除死代码将会给你的发布工程师带来相当多的问题：这样的改动之后基本不可能有任何程序能跑起来。

所有这些最差的部分是什么？2012年早些时候，Google做了一个分析发现，就前面提到的数据留存设定之下，大部分C++的flags的值从来没有被改变过。

Flags在特定情况下是合适的，然而：调试那些没有flag的调用栈真的不一样。特性flags，在合适地处理（并且在使用后清理）的情况下，是完全合理的。那些需要被英勇的SRE（译者注：Site Reliability Engineer）调节的“把手”是便利的安全网。更广泛地说，只在main()中使用的，为程序传入名字/值的输入的flags，要比到处占坑的参数容易维护得多。

有了这么多的坑，我们是时候使劲儿看看我们对flags的使用了。下次你手欠想给你的库加一个flag的时候，花点时间找找更好的方式。显式地传递配置：这几乎总是更容易被合适地使用，并且绝对更容易维护。考虑将数值flag改为编译期常量。如果你给别人做代码审查时遇到了新的flag，怼回去。每引入一个新的flag都应该有合理的解释。