最近，在使用常量的代碼reveiw會話期間引起了很大的爭議。 開發商曾使用常量用於以下目的：對消息密鑰和數據庫表名稱和列名使用常量
在任何應用程序中擁有如此巨量的常量是否有意義？恕我直言，常識應該佔上風。消息密鑰不需要聲明爲常量。我們已經有了一個間接的層次 - 爲什麼要添加一個？
Reg。數據庫的列名，我有不同的看法。如果某個列在多個類中使用，將它聲明爲全局常量是否合理？
請與您的想法紛至沓來......
如果常量是多使用地方和的編譯真正抓住問題的，是的。
這取決於編程語言，我認爲。
在PHP中，ude定義aka contants用於這樣的事情並不罕見，而我不會在Java或C＃中使用它。
在大多數項目中，我們試圖將SQL提取到模板，所以不僅表和列名是可配置的，而且是整個sql語句。我們將速度用於基本模板機制（如變量，小循環）...
關於語言常量： 另一層對我來說沒有多大意義，但您必須仔細選擇語言翻譯的標識符。如果你在英語句子中修改措辭而不改變意思，那麼使用全英文句子作爲關鍵詞可能會給譯員帶來很多工作。所以所有的譯員都必須更新他們的文件。
我認爲將i18N用作常量的消息密鑰是一種很好的做法。 如果你有一個設計良好的持久層，我不會在DB列中看到很多好處。
如果I18N消息密鑰沒有被定義爲常量，你如何執行一致性？你如何自動區分錯字和缺失值？您如何審覈以確保每個新語言文件都符合所有I18N密鑰？
至於數據庫列，你可以肯定地使用一些間接 - 如果你的應用程序知道列名，你有一個綁定的問題。所以在那裏，你可能會考慮一個帶有實際列名的配置文件 - 但是當然，你會想通過符號鍵引用列名，它應該被定義爲可審計的常量，就像I18N鍵一樣。