本周小贴士#45：避免标志，尤其是在库代码中

作为totw#45最初发表于2013年6月3日

由Titus Tinters创作

"由于我的代码被全局变量控制以至于无法进行静态预测，并且这种用法无法生成完整的日志，我真正想做的只能是非常艰难地将它们从我的代码中移除“——曾经的一个未留名的人

在进行生产的代码中，特别是库中，标志(flags)的通常用法是一个错误。除非确实需要，否则不要使用标志。这里，我们讲过了。

标志是全局变量，更糟糕的是：你无法通过阅读代码来知道变量的值。一个标志不仅在启动时会被设置，而且随后可能被任意的方式修改。如果你运行一个二进制文件的服务器，在不断的周期循环中，通常是无法保证这标志的值保持不变的，即便它改变了也无法获取通知，也无法通过任何方式来寻找这个改变。

如果你的生产环境直接记录了每个执行文件的调用，并保存了这些日志，那就太好了。大多数环境却不是这种方式。对于库代码而言，这种不确定尤为有害：你要如何确定一个特定的功能何时无效呢？简单的回答是：你不能。

标志同样会让在无效代码中添加最后的桩函数成功挑战。在迁移到新的后端过程中，你会认为删除旧代码仅仅是删除不必要的构造依赖并执行历史记录中最令人满意的git rm指令。你会出错。如果你的旧执行文件有几百个在生产代码中定义和引用的标志，那么简单地移除这些无效代码，对于你的发布工程师而言，可能产生大量的问题：在此类更改后，几乎没有任何作业(job)会启动。

所有这一切中最糟糕的部分是什么呢？Google在2012年初进行的一项分析发现，就我们在上述数据保存而言，多数C++标志实际上从未变化。

标志在某些情况是适合的，但是：在没有开启标志的回溯下调试就会不一样。适当地处理(然后清除)特性标识是完全合理的。更广泛地说，标志被用作名字/值输入传递给执行文件，并且仅用在main()中，相比位置参数更具可维护性。

尽管有这些警告，我们所有人还是该认真查看标志的用法。下次你想在你的执行文件中添加标志时，请花点时间寻找更好的方法。显式地传递配置文件：这一直是一个容易正确推断的原因，并且更容易维护。考虑将数字标志转变为编译期常量。如果你在代码评审时遇到新添加的标志，请退回。每个标志的引入都应该有正当理由。