RE: [stellation-res] To what extent should literals be named?

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: September 3, 2002 2:58 PM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: Re: [stellation-res] To what extent should literals be named?
> >
> >
> >Here's my take on the literals issue:
> >
> >When a literal is used in exactly one place in the code, and it's easier
> >to read/understand as a literal than as a variable reference, you should
> >use the literal. So, for things like the places where you're referencing
> >command names, I'm mildly in favor of using the literal.
> >
> >When a string is being used for a purpose where the literal value
> >of the string does not clearly denote the purpose for which that
> >literal is being used, I'm strongly in favor of a named variable. For
> >example, in the case of the setState method, I'd prefer to see
> >Workspace.STATE_ZERO.
> >
> >When a string is used in several places in the program, and it always
> >has the same meaning, then I'm  in favor of replacing it by a named
> >constant. For example, the artifact types, or the common command options
> >like force.
> >
> >Finally, there should be some consistency... So, for example, if we
> >decide that the common command options are named variables, then
> >I'd like all options to be named variables. A half-and-half mix
> >gets hard to read, and confusing.
> >
> >For the i18n issue raised by Florin: that's a whole different kettle of
> >fish, and one which we haven't addressed at all, anywhere in our code.
> >It's worth someone doing at some point... But it's something we really
> >haven't thought about so far. If we want to do internationalization,
> >then that's a good argument for making all of the string literals in the
> >workspace into named variables, so that when someone wants to do the
> >actual internationalization work, it'll be a lot easier for them.
> >The catch, as usual, is resource issues. I don't want it to be done
> >halfway: if we're de-literalizing for internationalization, then we
> >should do it right, and do it everywhere, which makes it into a much
> >larger task. I'm not sure if anyone has the time to do that right now.
> >
> >	-Mark
> >

I would be prepared to take on this if you are willing and the team decides
to go this route. Incidentally, I agree with you that this should be
basically an all-or-nothing effort particularly in the light of i18n. I
completely forgot about that one. BTW in our shop even though we have not
internationalized yet we do have a standard of placing all strings except
for those destined for the log.
They represent a special case which can be argued separately if you decide
the basic approach is useful.

The problem with log messages is that they may need to be read by a
maintenance programmer whose language is different from that in the log.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx