使用消息键和数据库表名和列名的常量
最近，在代码审查会议期间，关于常量的使用发生了一场大辩论。 开发人员将常量用于以下目的：
- i18N 应用程序中使用的每个消息密钥都被声明为常量。该应用程序包含大约 3000 个消息键，因此包含相同数量的常量。
- 每个数据库列名都被声明为常量。大约有 5000 个列名并且仍在计数中。
在任何应用程序中拥有如此大量的常量是否有意义？ 恕我直言，常识应该占上风。消息键不需要声明为常量。我们已经有了一层间接——为什么还要再添加一层呢？
注册。数据库列名，我有不同的意见。如果一个列在多个类中使用，将其声明为全局常量是否有意义？
请说出你的想法...
Recently there was a big debate during a code reveiw session on the use of constants.
The developers had used constants for the following purposes:
- Each and every message key used in the i18N application was declared as a constant. The application contained around 3000 message keys and hence the same number of constants.
- Each and every database column name was declared as a constant. There were around 5000 column names and still counting..
Does it make sense to have such a huge number of constants in any application?
IMHO, common sense should prevail. Message keys just don't need to be declared as constants. We already have one level of indirection - why add one more?
Reg. database column names, I have mixed opinions. If a column is being used in multiple classes, does it make sense to declare it as a global constant?
Please pour in with your thoughts...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果 I18N 消息键未定义为常量，如何强制一致性？如何自动区分拼写错误和缺失值？您如何审核以确保每个新语言文件中都满足所有 I18N 密钥？
至于数据库列，您绝对可以使用一些间接方法 - 如果您的应用程序知道列名称，那么您就会遇到绑定问题。因此，您可能会考虑使用具有实际列名称的配置文件 - 但当然，您会希望通过符号键引用列名称，这些符号应该定义为可审计常量，就像 I18N 键一样。
If I18N message keys aren't defined as constants, how do you enforce consistency? How do you automatically differentiate between a typo and a missing value? How do you audit to make sure that all I18N keys are fulfilled in each new language file?
As to database columns, you could definitely use some indirection - if your application knows about column names, you've got a binding problem. So there, you might consider a config file with the actual column names - but of course, you would want to refer to the column names by symbolic keys, which should be defined as auditable constants, just like the I18N keys.
我认为将用于 i18N 的消息键作为常量是一个很好的做法。
如果你有一个设计良好的持久层，我认为对数据库列做同样的事情并没有多大好处。
I think is a good practice to put message keys used for i18N as constants.
I don't see much benefits in doing the same for the DB columns, if you have a well designed persistence layer.
我认为这取决于编程语言。
在 PHP 中，使用 ude 定义此类内容的情况并不少见，但我不会在 Java 或 C# 中使用它。
在大多数项目中，我们尝试将 SQL 提取到模板中，因此不仅表名和列名是可配置的，整个 sql 语句也是可配置的。我们将速度用于基本模板机制，例如变量、小循环……
关于语言常量：
另一层对我来说没有多大意义，但是您必须仔细选择用于语言翻译的标识符。如果您修复英语句子中的措辞而不改变含义，那么使用整个英语句子作为关键可能会给译者带来大量工作。因此所有翻译人员都必须更新他们的文件。
This depends on the programming language, I think.
In PHP it's not uncommon to ude defines aka contants for such things, while I'd not use this in Java or C#.
In most projects we tried to extract the SQL to templates, so not only the table and column names were configurable but the whole sql statement. We used velocity for basic templating mechanics like variables, small loops,...
Regarding the language constants:
Another layer doesn't make much sense to me, but you hav eto choose your identifiers for the language translation carefully. Using the whole english sentence as key may end up in a lot of work for the translators if you fix the wording for example in the english sentence without changing the meaning. So all translators would have to update their files.
如果常量在多个地方使用并且编译器确实发现了问题，是的。
If the constant is used in multiple places and the compiler really catches the problem, yes.