静态常量、enum、魔法字符串（数字）的选择

最近在阅读公司旧代码，发现了很多的魔法数字或者字符串，突然想起几年前和同事讨论的《什么时候采用常量，什么时候采用enum》事情，于是回忆一下，并加上对魔法字符的比较，并记录一下。

先简单的对比一下

• 直接使用字符串

  • 好处

    • 直观明了，一眼就知道了这个值是什么意思，如：ServiceName意思就是服务名

    • 修改方便，且影响小，只影响当前修改的地方，不影响其他任何地方

  • 坏处

    • 如果值不是可读性强的内容，会导致理解起来费劲，如：outopgro，这种才用了缩写的字段，或者过长的字段

    • 分散在代码中，不利于统一管理：如果同一个字符串使用的地方过多，那么需要修改字符串的时候，就容易漏掉一些

• 使用常量

  • 好处

    • 可以定义一个比较有意义的名字，这样在使用的时候，比较容易理解起内容

    • 统一管理，维护起来比较方便

  • 坏处

    • 容易误用，导致修改时影响到不该影响的地方：这个只能靠规范化、代码review去要求好

• 使用enum

  • 好处

    • 与常量一样，统一进行管理，方便维护

    • 相比上面两种，增加了类型的检测，不仅仅是值的检测，如检查状态时，多了状态类的类型检查

  • 坏处

    • 一般同一个类型里面，不能够不建议定义过多内容

各种适配场景对比

根据上面的对比，简单总结了下三种类型的不停的使用场景

• 字符串、数字等直接的值：只要是可控、可维护的范围，那么就可以使用，大体可以参照下面的东西

  • 出现次数比较少，一般检测工具要求不超过3次

  • 出现范围比较小，例如只在一个class中或者一个方法中使用，不会在很多地方使用

  • 需要动态拼接的字符串，或者需要直接看到内容的地方，如拼接SQL，如报错信息：“XXX服务，出现了XXX错误，请注意！”

• 常量：范围广，变量以取值为主，不需类型匹配

  • 一些全局性的变量，如定义系统的error code

  • 与其他服务交互时的一些固定变量，如前端控件的名字，其他服务的名字

  • 一些动态属性的静态字段，如动态表单中的一些常见属性

• 枚举：取值比较固定，专项引用的地方

  • 如：单据状态、用户状态