使用常量作为消息键和数据库表名称和列名称

Question

最近在关于常量使用的代码启示会议期间发生了很大的争论。 开发人员将常量用于以下目的：

1. i18N应用程序中使用的每个消息密钥都被声明为常量。该应用程序包含大约3000个消息密钥，因此具有相同数量的常量。
2. 每个数据库列名称都声明为常量。大约有5000个列名，仍在计数..

在任何应用程序中拥有如此大量的常量是否有意义？ 恕我直言，常识应占上风。消息键不需要声明为常量。我们已经有一个间接级别 - 为什么再添加一个？

注册。数据库列名，我的意见不一。如果在多个类中使用列，将它声明为全局常量是否有意义？

请注意你的想法......

Answer 1

如果I18N消息密钥未定义为常量，您如何强制执行一致性？你如何自动区分拼写错误和缺失值？您如何进行审核以确保在每个新语言文件中都满足所有I18N密钥？

对于数据库列，你绝对可以使用一些间接 - 如果你的应用程序知道列名，你就会遇到绑定问题。那么，您可以考虑使用实际列名称的配置文件 - 当然，您可能希望通过符号键引用列名称，这应该被定义为可审计的常量，就像I18N键一样。

Answer 2

我认为将i18N使用的消息密钥作为常量是一种很好的做法。 如果您有一个设计良好的持久层，我认为对DB列执行相同操作并没有多大好处。

Answer 3

如果常量用于多个位置和，编译器确实可以解决问题，是的。

Answer 4

这取决于编程语言，我认为。

在PHP中，ude定义了这些东西的含义并不罕见，而我不会在Java或C＃中使用它。

在大多数项目中，我们尝试将SQL提取到模板，因此不仅可以配置表名和列名，还可以配置整个sql语句。我们使用速度进行基本的模板机制，如变量，小循环，......

关于语言常量： 另一层对我来说没什么意义，但是你要仔细选择语言翻译的标识符。如果你在英语句子中修改措辞而不改变含义，那么使用整个英语句子作为关键可能会为翻译人员做很多工作。所以所有翻译人员都必须更新他们的文件。