任何好用的工具如果使用不当都会带来不好的后果，gflags也是一样。我遇到过一些gflags的“坑”，还从领导和同事那里获得一些好的想法，整理成7条gflags使用规范。有意识的遵循这些规范，对项目的开发维护和自身的技术成长都将有很大的益处。
规范1：bool类型的gflags默认值设置成false，防止误启用新功能。
新的功能上线一定要经过代码审查、测试和验证流程，默认为true的gflags风险太大。
规范2：应定时清理旧的gflags。
随着时间的流逝，代码里的gflags会越来越多，当你的工程代码里包含成百上千行的gflags时，阅读和维护代码的体验简直是太过酸爽。非常有必要定时删除代码中旧的gflags，根据其开关打开（true）和关闭（false）情况来删除gflags及其相关代码。
规范3：清理旧的gflags时应同时删除相应的gflags配置，以保证线上配置的整洁。
配置文件和代码保持同步是一种非常好的开发和维护体验。
规范4：if语句中应尽量避免gflags参与逻辑运算。
当if语句中出现与gflags相关的与、或、非逻辑运算时，事情就会变得复杂起来，gflags的开关状态不再是唯一的决定因素，代码阅读和删除gflags也会变得十分困难。我曾经删错过一个旧的gflags，幸运的是在CR阶段（CodeReview，代码审查）被细心的同事指出，避免了一次踩坑。这是那段令我难忘的代码的样子：
在这个例子中同时出现了与、或、非这3个逻辑运算，它是工程中真实存在的代码，绝非由我杜撰。此时gflags a、b、c、d的值都是false，现在的任务是删除这些旧的gflags和它们包住的代码，应该保留哪部分代码呢？如果你和我一样忘记了或运算||和与运算&&谁的优先级更高，那么掉到坑里的概率非常大。言归正传，我们有很多方法避免这样的代码出现，gflags绝不应该参与复杂的逻辑运算。
规范5：公共模块的gflags应尽快删除。
公共模块的gflags在上线运行一段时间后，应尽快删除，理想的情况是公共模块都没有gflags包含。这样做的理由是使用公共模块往往不知道这些gflags的存在，非常容易留坑。
规范6：不要在单元测试代码中使用gflags。
如果UT（UnitTest，单元测试）代码里用到了gflags，情况会变得复杂，在删除旧的gflags时需要同步修改单元测试代码，否则会导致测试失败，jenkins上的任务会变红（即测试失败）。因此，最好不要在单元测试代码里使用gflags。
规范7：提交代码时，应记录新增或删除的gflags配置。
这样的好处是方便测试的同事进行测试，这样利人利己的规范是非常值得遵守的。
最后，我把这7条规范总结并整理成一张图片，欢迎大家留言补充更多、更好的gflags使用规范。
金句分享
人的天性之一，就是不会接受别人的批评，总是认为自己永远是对的，喜欢找各种各样的借口为自己辩解。
——出自《人性的弱点》，戴尔·卡耐基(Dale Carnegie)，美国著名人际关系学大师。
解读：永远不要批评别人，因为指责只不过是在浪费自己和他人的时间，应该换种方式去沟通和解决问题。