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 Jim Wright -
> >IBM Research
> >Sent: September 4, 2002 9:40 AM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: Re: [stellation-res] To what extent should literals be named?
> >
> >
> >I generally agree with Mark.
> >* If a literal is used more than once, make it a named variable.
> >* Use string literals in log statements (unless there's a good
> >counter arg,
> >   per Jonathan's comment re: maintenance programmers who prefer
> >   non-English log statements).

Much more common - the English speaking maintenance programmer who has to
deal with a localized log from Japan.


> >* Defer the i18n issue for now, but code with it in mind.  Later, do a
> >   proper job to handle it.
> >
> >- Jim
> >
> >At 06:58 PM 9/3/02 +0000, Mark C. Chu-Carroll wrote:
> >>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


Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx