什么时候最适合重构字符串文字？
我正在开始一个项目，其中大部分时间都将字符串写入代码中。 许多字符串可能只在少数地方使用，但有些字符串在许多页面中都是通用的。
由于应用程序已经建立得很好并且运行良好，因此我可以很好地利用我的时间将文字重构为常量吗？ 这样做的长期好处是什么？
I'm starting on a project where strings are written into the code most of the time. Many strings might only be used in a few places but some strings are common throughout many pages.
Is it a good use of my time to refactor the literals into constants being that the app is pretty well established and runs well? What would be the long-term benefits to doing so?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
需要考虑的一个常见问题是i18n。 如果您（或您的混蛋）想在墨西哥或法国（等）销售您的产品，那么您会喜欢这些字符串文字不散布在整个代码库中。
编辑：我意识到这并不能直接回答你的问题，所以我对其他一些答案进行投票：三法则等。 我知道您正在谈论现有的代码库，因此从一开始就谈论合并 i18n 有点晚了。 当您从一开始就养成这个习惯时，这很容易做到。
One common thing to consider would be i18n. If you (or your muckity-mucks) ever want to sell your product in Mexico or France (etc.) you're going to appreciate having those string literals not littered throughout the code base.
EDIT: I realize this doesn't directly answer your question, so I'm voting up some of the other answers re: rule of three, and the like. I understand you're talking about an existing code base, so it's a little late to talk about incorporating i18n from the start. It's so easy to do when you're in the habit from the start.
我喜欢在重构时应用三法则。 如果发生三次或更多次，则需要更新代码。
I like to apply the rule of three when refactoring. If it happens three or more times, then the code needs to be updated.
只有当这个项目需要在未来得到支持时，这才是很好的利用时间。 您是否会定期维护/扩展该系统； 然而，这是一个好主意。
1) 与字符串文字相关的风险很大，因为单个拼写错误通常只能在运行时检测到。 降低运行时错误的风险是一个重要的优势，因为它们可能会令人尴尬/沮丧。
2）此外，如果它们需要更改，例如当它们用于引用另一个系统（如表名称、服务器名称等）时，当其他系统名称发生更改时，它们可能很难更新。 将它们集中起来，这是一个微不足道的问题。
Only if this project needs to be supported into the future is this a good use of time. If you will be regularly maintaining/expanding this system; however, this is a great idea.
1) There is a large degree of risk associated with string literals as a single misspelling can usually only be detected at run time. The reduced risk of run time errors is a serious advantage as they can be embarrassing/frustrating.
2) Also, should they ever need to be changed, for example when they are used to reference another system (like table names, server names etc) they can be very difficult to update when those other system names change. Centralize them and it's a trivial issue.
如果一个字符串在多个地方使用，请重构它。 如果仅在一处使用，则不要管它。
If a string is used in more than one place, refactor it. If it is only used in one place, leave it alone.
如果您重构了所有常用字符串，则可以更轻松地国际化/翻译它们。 如果它们都在属性文件中，或者任何您的语言等效文件中，那就更容易了。
If you've refactored out all your common strings, it makes it easier to internationalize/translate them. It's even easier if they're all in properties files, or whatever your language equivalent is.
不，您最好保持原样。
如果没有人接触过该代码，那么好处就没有。
然而，您可以做的是避免添加新的文字。 但我几乎会保持现状。
你或许可以在空闲时重构它们，以便睡得更好。
可能还有一些其他错误需要您注意。 修复这些问题。
最后，如果你设法将“重构”添加到你的任务列表中，那就继续吧！
No, you better leave it like it is.
If no one ever touch that code, the benefits are none.
What you can do, however is avoid adding new literals. But I would pretty much leave existing the way they are.
You could probably refactor them in your free to sleep better.
Probably there are some other bugs already that need your attention. Fix those instead.
Finally, if you manage you add "refactoring" to your task list, go ahead!!!
我同意 JMD，请记住，i18n 不仅仅是更改字符串（货币、UI 必须适应从右到左的语言等），
即使您不希望 18n 您的应用程序，这也会很有用重构您的字符串，因为该字符串今天仅使用一次，明天可能会重复使用多次，如果它是硬编码的，您可能不会意识到它并在各处复制字符串。
I agree with JMD, just keep in mind that there is more to i18n than changing strings(currencies, UI must be adpated to Right-to-left languages etc)
Even if you don´t wish to 18n your application it would be useful to refactor your strings, since that string that is used today only once, maybe reused tomorrow several times, and if it´s hardcoded you may be not aware of it and star replicating string all over the place.
最好让熟睡的狗躺着。 如果您需要更改使用了十八次的字符串，是的，请继续将其转换为常量。 如果您发现自己正在使用一个具有可以常量化的字符串的模块，如果您愿意，就可以这样做。 但是浏览整个应用程序将所有字符串更改为常量......这应该位于待办事项列表的最底部。
Best let sleeping dogs lie. If you need to change a string that's used eighteen-lumpy times, yeah, go ahead and turn it into a constant somewhere. If you find yourself working in a module that has a string that could be constant-ize, do it if you feel like it. But going through the whole app changing all strings to constants... that should be on the very bottom of the to-do list.