阿里编程规约之命名风格和常量定义

各位好，今天我们要谈的是代码的命名风格和常量定义。这两个条目偏开发习惯而不是技术。可以说，你不去管这两个方面的要求，也可以写出可运行的程序。但是，可能就只能止步于可运行了。对于后续的扩展，他人的迭代更新来说，大概率会造成很多困扰。这也是为什么要在一个团队里不断强调统一规范的命名和常量的原因吧。
下面我们一起看一下命名风格有关脑图

我一直认为写代码和写文章差不多。我们看别人的代码，其实和看别人写的文章一样，只是我们学了十几年的中文，对语法什么的已经很自然的理解了。但是我们大多数人对于java的语法是没达到这么精深的程度的。另外，我们看文章，如果想了解某段话的意思的话，是需要先知道这段话的上下文的。即对话的场景。这个上下文相信大家也不陌生。context是spring核心模块之一。所以，从这两点看，其实命名，重要的是在合适的场景用大家都认可的说法。上面有一条，杜绝完全不规范的缩写，避免望文生义。其实这里的命名规范不止是开发适用，某些点产品和测试都是适用的。代码和项目文档都是项目的产出之一。理论上应该是要保持统一的命名的。
至于常量定义，我个人认为就比较教条化了，可以通过统一的规范的代码格式化实现，具体开发手册里说了啥，我下面都列出来了，请大家自行阅读~

(二)常量定义
1. 【强制】不允许任何魔法值（即未经定义的常量） 直接出现在代码中。
反例： String key = "Id#taobao_" + tradeId;
cache.put(key, value);
2. 【强制】 long 或者 Long 初始赋值时， 使用大写的 L，不能是小写的 l，小写容易跟数字 1 混
淆，造成误解。
说明： Long a = 2l; 写的是数字的 21，还是 Long 型的 2?
3. 【推荐】不要使用一个常量类维护所有常量， 按常量功能进行归类，分开维护。
说明： 大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
正例： 缓存相关常量放在类 CacheConsts 下； 系统配置相关常量放在类 ConfigConsts 下。
4. 【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包
内共享常量、类内共享常量。
1） 跨应用共享常量：放置在二方库中，通常是 client.jar 中的 constant 目录下。
2） 应用内共享常量：放置在一方库中， 通常是 modules 中的 constant 目录下。
反例： 易懂变量也要统一定义成应用内共享常量，两位攻城师在两个类中分别定义了表示
“是”的变量
           类 A 中： public static final String YES = "yes";
           类 B 中： public static final String YES = "y";
A.YES.equals(B.YES)，预期是 true，但实际返回为 false，导致线上问题。
3） 子工程内部共享常量：即在当前子工程的 constant 目录下。
4） 包内共享常量：即在当前包下单独的 constant 目录下。
5） 类内共享常量：直接在类内部 private static final 定义。
5. 【推荐】如果变量值仅在一个范围内变化，且带有名称之外的延伸属性， 定义为枚举类。下面
正例中的数字就是延伸信息，表示星期几。
正例： public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6),
SUNDAY(7);