代码审查实践经验分享——应该是大写还是小写？
作者这么辛苦，不先关注再读，你过意得去吗？以下正片开始。
最近团队开始推广代码审查机制。每个人的代码在合并到master之前都要进行审查。
今天，团队因为一个大小写问题“吵”了起来。这是代码审查机制推广路上必须要经过的。
问题是这样的。我们对SLF4J的 log进行了一次包装。同事的代码是这样的：
@Slf4j
public class HelloWorld {
private static final Telemetry TELEMETRY = Telemetry.build(log);
}
大家吵的焦点是 telemetry这个“常量”到底应该使用大写还是小写。
支持大写的人认为：
规范里写了常量要大写，我们要遵守规范。
它是常量，应该使用大写。
支持小写的人认为：
log为什么要小写？
全大写观感不好。
全大写，写起来也不舒服。
双方都面红脸赤了，还争执不下来。还好饭点到了，大家各自要去吃饭了。气氛终于平静下来。最后，达成了一个共识：只要大家投票通过，该大写就大写，该小写就小写。
经历过这次，加上以前的经验，我总结：集体代码审查的活动最好安排在下班前，而不是上班前。
吃饭过程中，笔者就在思考，为什么行业里的 log都是小写的。心想一定有人提问过。饭后，一搜索，果然有人在stackoverflow问了。
的确，常量名命名模式为CONSTANT_CASE，全部字母大写，用下划线分隔单词。
但是， staticfinalSet<String>mutableCollection=newHashSet<String>();中的 mutableCollection是常量吗？
所以，我们争执的问题的关键点是 privatestaticfinalTelemetryTELEMETRY=Telemetry.build(log);中的 TELEMETRY是常量吗？更进一步要问的是什么是常量？
在stackoverflow的帖子中，有一个解释：staticfinal修饰的对象引用不能跟 .，否则它就不是常量。可是， staticfinalStringhello="world"中的 hello是可以跟 .的，所以，这个解释是行不通的。
在通读这些帖子后，个人觉得Google的Java代码风格(https://google.github.io/styleguide/javaguide.html#s5.2.4-constant-names)给的解释最令人信服：
Every constant is a static final field, but not all static final fields are constants. Before choosing constant case, consider whether the field really feels like a constant. For example, if any of that instance's observable state can change, it is almost certainly not a constant. Merely intending to never mutate the object is generally not enough.
意思就是static final字段可以是一个常量，但是并不是所有的static final字段都是常量。常量与非常量之间的区别是它的状态是否会被改变。
以下是例子：
回到最初的问题，TELEMETRY是变量，应该小写。
但是，在整个调查过程中，有两个发现：
阿里巴巴的P3C工具似乎要求所有的static final的字段都被当成常量处理。
著名的代码扫描工具SonarQube，要求Logger全大写。规则地址：https://rules.sonarsource.com/java/tag/convention/RSPEC-1312
小结
代码审查机制推广的过程是团队成员成长的过程，会有阵痛；
代码审查机制在推广时就必须时刻提醒大家，争吵是必然，但是不能人身攻击；
团队成员在讨论代码规范时，还是需要把个人喜好带入讨论中，这是代码审查中的忌。比如我一开始就说大写对观感和手写体验；
有时工具并没完美；
大小写问题只是问题的表面，真正的问题是，常量到底是什么。这就是我们的规范需要不断完善的地方。我们在翻阿里巴巴Java规范时，没有找到常量的定义；
集体代码审查的活动最好安排在下班前，而不是上班前，这样更容易达成共识。
附录：
stackoverflow原帖地址：https://stackoverflow.com/questions/1417190/should-a-static-final-logger-be-declared-in-upper-case