| 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 -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center *** The Stellation project: Advanced SCM for Collaboration *** http://www.eclipse.org/stellation *** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part