String Externalization

[Jason Cavett]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's
big), is there any reason to incur the overhead (time to implement,
overhead of the use of Properties, etc) to convert an application so
it uses a .properties file.

Just curious what other developer opinions are.

Thanks.

 

[Mark Space]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings

But Mousie, thou are no thy-lane,
In proving foresight may be vain:
The best laid schemes o' Mice an' Men,
Gang aft agley,
An' lea'e us nought but grief an' pain,
For promis'd joy!

-- Robert Burns, _To A Mouse_

 

[Tom Anderson]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's big),
is there any reason to incur the overhead (time to implement, overhead
of the use of Properties, etc) to convert an application so it uses a
.properties file.

Just curious what other developer opinions are.

Hard-code them; it's a complete waste of effort to do otherwise if you
don't actually need that feature, and usually, You Aren't Gonna Need It.
If it turns out you do need it, go back and change them to use a
properties file or whatever. To make this a simple change, collect them
all in one place. Something like:

public class Messages
{
public static String theFileCouldNotBeOpened() ;
public static String theFileCouldNotBeClosed() ;
public static String iOpenedYouAFileButIEatedIt() ;
public static String youAreLikelyToBeEatenByAGrue() ;
}

// time passes ...

try
{
f.close() ;
}
catch(IOException e)
{
notifyUser(Messages.theFileCouldNotBeClosed()) ;
if (!light.isOn())
notifyUser(Messages.youAreLikelyToBeEatenByAGrue()) ;
}

In general, you shouldn't add features to a program unless you need them,
but you should leave the way open to add them in the future. In other
branches of engineering, it's called "fitting for but not with", or
"passive provision".

tom

 

[Leonard Milcin]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's
big), is there any reason to incur the overhead (time to implement,
overhead of the use of Properties, etc) to convert an application so
it uses a .properties file.

Just curious what other developer opinions are.

Thanks.

It isn't that hard. Most IDEs have some way to do this automatically.
Rather, ask yourself whether you will benefit in any way from it. Do you
plan
to translate your interface? If yes -- do it. If not -- don't waste your
time.

Regards,
Leonard

 

[Arne Vajhøj]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's
big), is there any reason to incur the overhead (time to implement,
overhead of the use of Properties, etc) to convert an application so
it uses a .properties file.

If you can see in the future and therefor can be sure that
those strings will not be changed, then you are in a very
fortunate position.



Experience show that code tend to be used much longer than
original intended.

So let us say that there are very good reason to consider
externalizing those strings.

We live in a global world and it is not so unrealistic
to suddenly need to support other languages.

But note that there is a big difference in having
string literals spread out in all classes directly
in the method calls and having a few classes with
a bunch of final static strings.

With the last approach it is a lot easier to change
things than with the first approach.

Arne

 

[Roedy Green]

I know, generally, hard coding strings is not the best thing in the
world to do. However, if I am not planning on changing those strings
(especially if the application has already been written - and it's
big), is there any reason to incur the overhead (time to implement,
overhead of the use of Properties, etc) to convert an application so
it uses a .properties file.

There are two flavours of string in your program, ones that would be
translated into Spanish if you ever ported your program to Spanish and
ones that would remain invariant. If you do an English-only version,
you might consider extracting all translatable strings and giving them
constant names with some consistent prefix. That will make it a
relatively mechanical process for another programmer to port the
program later, if needed.

see http://mindprod.com/jgloss/localisation.html

 

[Jason Cavett]

But Mousie, thou are no thy-lane,
In proving foresight may be vain:
The best laid schemes o' Mice an' Men,
Gang aft agley,
An' lea'e us nought but grief an' pain,
For promis'd joy!

              -- Robert Burns, _To A Mouse_

I understand your point, but, at the same time, I can't do it unless I
have a reason to do it.

 

[Mark Space]

I understand your point, but, at the same time, I can't do it unless I
have a reason to do it.

There can be a fine line between gold-plating and prudent software
engineering best practice. Without extensive knowledge of your
requirements and your business, I don't see how we can advise you.
You'll have to make your own call.