String Externalization (reasons as to why)

[Greg Reeder]

Hi,

I saw an option in the refractering menu of eclipse that allows a user to externalize strings. That got me wondering, why would a programer wish to have string externalized and placed into a seperate text file? Other than allowing for multiple languages that are easy to check because the are all in one place, I cannot imagine how this could be helpful. Any thoughts?

Greg

[Winston Gutkowski]

Greg Reeder wrote:I saw an option in the refractering menu of eclipse that allows a user to externalize strings. That got me wondering, why would a programer wish to have string externalized and placed into a seperate text file? Other than allowing for multiple languages that are easy to check because the are all in one place, I cannot imagine how this could be helpful. Any thoughts?

It appears to be a form of indirection, although I have to admit I've never used it for anything but language translation. However, it may well be useful for configuring application messages without the need to recompile.

There's a discussion about it here; but I can't guarantee how good it is.

Winston

[Stephan van Hulst]

[edit]

d'oh, nevermind, I misread.

[Greg Reeder]

Thank you all very much. I guess then it is there as a good solution to a few issues that might pop up in the life of a programmer, but it is not a "law of programming" that all strings in a class be externalized.


Thank you!

[Jayesh A Lalwani]

There are no laws in programming. Everything you do is for a purpose, Understand the purpose, you must first.

[Winston Gutkowski]

Jayesh A Lalwani wrote:There are no laws in programming...

Maybe not, but there are a few good rules to live by:

Don't re-invent the wheel.

Don't repeat yourself.

and

Keep it simple, stupid.

not being bad ones to start with.

Winston

[Jayesh A Lalwani]

Yes, true, but then again those rules are there for a purpose, and you have to to understand the purpose first. For example, rules like "Implement your code to be legible" and "Code should be self-explanatory" are pretty universal (atleast with Java programmers) but get routinely broken when you build Linux shell scripts. The reason is that the rules make sense when you are working on long term projects with multiple developers:- The purpose of those rules is to make it easier for other developers to understand your work.

However, if you are writing scripts that only one person uses, and never needs to maintain, who cares about documentation? Indeed, once you get into an environment where shell scripts are being developed and maintained by a team of developers, you need to start making them more legible. This is something that even the more seasoned Java developers forget to do when they write scripts.