Using constants for message keys and database table names and column names

There has been a lot of debate during the code session lately about the use of constants. The developers have used constants for the following purposes:

  • Each message key used in the i18N application has been declared as a constant. The application contained about 3000 message keys and therefore the same number of constants.
  • Each database column name was declared as a constant. There were about 5,000 column names and it was still considered ..

Does it make sense to have so many constants in any application? IMHO, common sense should prevail. Message keys just don't have to be declared as constants. We already have one level of indirection - why add another one?

Reg. database column names, I have mixed opinions. If a column is used in multiple classes, does it make sense to declare it a global constant?

Please fill in your thoughts ...

+2


source to share


4 answers


If the keys of the I18N message are not defined as constants, how do you ensure consistency? How do you automatically distinguish between a typo and a missing meaning? How do you audit to make sure all I18N keys are executed in every new language file?



As far as database columns go, you can definitely use some indirection - if your application knows the column names, you have a binding problem. Thus, you can consider a config file with the actual column names, but of course you would like to refer to the column names using symbolic keys, which must be defined as testable constants, just like the I18N keys.

+2


source


I find it good practice to use the message keys used for the i18N as constants. I don't see much benefit in doing the same for DB columns if you have a well thought out persistence level.



+1


source


If the constant is used in several places and , the compiler will really catch the problem, yes.

0


source


It depends on the programming language I guess.

In PHP, it's not uncommon for ude to define aka contants for things like this, while I won't use that in Java or C #.

In most projects we tried to extract SQL templates, so not only the table and column names were customizable, but the whole sql statement. We used speed for basic modeling mechanisms such as variables, small loops, ...

Regarding language constants: Another level doesn't make much sense to me, but you choose your identifiers carefully for translating the language. Using the entire English sentence as a key can end up with a lot of work for translators if you correct the wording, for example, in an English sentence, without changing the meaning. Thus, all translators will have to update their files.

0


source







All Articles