«

On 12/14/2012 02:35 AM, William Bonawentura wrote:
>
>> Strings should be always created via out-of-code resources".
>> You just now broke your own rule with your annotation example;
>
> String literal inside annotation is not equal to literal inside code. It
> is like static constans - you can read it on code-buld phase ex. by
> Annotation Processor.
>
>> the absurdity of your rule is what Eric was trying to illustrate.
>
> There is good a "rule of life" . Never create literals in the code.

It's *all* code, William. As far as I am concerned, every single byte of
a *.java source file is code. Annotations absolutely are code, they are
also instructions to the computer.

AHS

> Then how would you do the following?
> public boolean isGetMethodName( String methodName ) {

It seems to me, that isGetMethodName is a internal part of reflecion-based library. Not a final / business / application code.

> It's *all* code, William. As far as I am concerned, every single byte of a *.java source file is code. Annotations absolutely are
> code, they are also instructions to the computer.

OK. Refine:

You should never create runtime computed literals inside your business code.

On 12/14/12 2:50 AM, William Bonawentura wrote:
>
>> It's *all* code, William. As far as I am concerned, every single byte
>> of a *.java source file is code. Annotations absolutely are code, they
>> are also instructions to the computer.
>
> OK. Refine:
>
> You should never create runtime computed literals inside your business
> code.
More refined:
You should never create an absolute rule. There are always exceptions.
Except for this rule.

It's a guideline to avoid "magic" values, but not all inline literals
are "magic".

For instance, I have seen people avoid "?" and "&" by introducing the
constants QUESTION_MARK and AMPERSAND. This is bad.

On 12/14/2012 11:24 AM, Daniel Pitts wrote:
> For instance, I have seen people avoid "?" and "&" by introducing the
> constants QUESTION_MARK and AMPERSAND. This is bad.

I wonder, in general, where the line should be drawn? Java coding
guidelines recommend that 1 and -1 can be used as literals, but other
integer constants should defined as a "constant" by the programmer.

I'm not sure that single character strings, or characters, should be
treated the same way. I can see cases for it, and I can see reasons for
not doing so, as Daniel implies.

Here's a grab from a recent discussion on transforming \u sequences in a
Java string. This is the bit in the Properties object that scans a line
read from a properties file for special escape sequences. I don't think
that the Java source APIs are the be-all and end-all of code style, but
it is a large public body of well-reviewed code. Note the abundant use
of single character constants, with out a programmer introduced
constant. It seems to read OK to me.


while (keyLen < limit) {
c = lr.lineBuf[keyLen];
//need check if escaped.
if ((c == '=' || c == ':') && !precedingBackslash) {
valueStart = keyLen + 1;
hasSep = true;
break;
} else if ((c == ' ' || c == '\t' || c == '\f') &&
!precedingBackslash) {
valueStart = keyLen + 1;
break;
}
if (c == '\\')
precedingBackslash = !precedingBackslash;
else
precedingBackslash = false;
keyLen++;
}

On Fri, 14 Dec 2012 11:47:21 -0800, markspace <-@.> wrote:

>On 12/14/2012 11:24 AM, Daniel Pitts wrote:
>> For instance, I have seen people avoid "?" and "&" by introducing the
>> constants QUESTION_MARK and AMPERSAND. This is bad.
>
>I wonder, in general, where the line should be drawn? Java coding
>guidelines recommend that 1 and -1 can be used as literals, but other
>integer constants should defined as a "constant" by the programmer.

What about zero?


Why should limit myself to just one line?

I draw a line between things that are unlikely to change and
those that may well change. Yes, I know that this is still blurry.

If I were writing code to do record blocking and deblocking, I
would not use literals in the work code for the physical and logical
record lengths.

If I were writing code dealing with weeks, I might well use 7 for
the number of days in a week.

I draw another line between simple (where I am much less likely
to bother) and complex (where I am much more likely to).

If the constants are local to just one procedure/method or a
short class, I might not bother. If the constants are used in more
than one place, I almost certainly will.

I draw a third line between temporary code and permanent code.
The former, unlikely; the latter, likely.

(Make sure that your "temporary" code really is temporary.)

>I'm not sure that single character strings, or characters, should be
>treated the same way. I can see cases for it, and I can see reasons for
>not doing so, as Daniel implies.

It depends to me on what their use is. Run-of-the-garden use, as
in the code example you posted, hardly needs it.

>Here's a grab from a recent discussion on transforming \u sequences in a
>Java string. This is the bit in the Properties object that scans a line
>read from a properties file for special escape sequences. I don't think
>that the Java source APIs are the be-all and end-all of code style, but
>it is a large public body of well-reviewed code. Note the abundant use
>of single character constants, with out a programmer introduced
>constant. It seems to read OK to me.

Likewise to me. It is short though so it does not prove much.
Were it a couple of pages long, it would be more of a test.

[snip]

Sincerely,

Gene Wirchenko

On Fri, 14 Dec 2012 11:47:21 -0800, markspace <-@.> wrote:

>On 12/14/2012 11:24 AM, Daniel Pitts wrote:
>> For instance, I have seen people avoid "?" and "&" by introducing the
>> constants QUESTION_MARK and AMPERSAND. This is bad.
>
>I wonder, in general, where the line should be drawn? Java coding
>guidelines recommend that 1 and -1 can be used as literals, but other
>integer constants should defined as a "constant" by the programmer.

What about zero?


Why should limit myself to just one line?

I draw a line between things that are unlikely to change and
those that may well change. Yes, I know that this is still blurry.

If I were writing code to do record blocking and deblocking, I
would not use literals in the work code for the physical and logical
record lengths.

If I were writing code dealing with weeks, I might well use 7 for
the number of days in a week.

I draw another line between simple (where I am much less likely
to bother) and complex (where I am much more likely to).

If the constants are local to just one procedure/method or a
short class, I might not bother. If the constants are used in more
than one place, I almost certainly will.

I draw a third line between temporary code and permanent code.
The former, unlikely; the latter, likely.

(Make sure that your "temporary" code really is temporary.)

>I'm not sure that single character strings, or characters, should be
>treated the same way. I can see cases for it, and I can see reasons for
>not doing so, as Daniel implies.

It depends to me on what their use is. Run-of-the-garden use, as
in the code example you posted, hardly needs it.

>Here's a grab from a recent discussion on transforming \u sequences in a
>Java string. This is the bit in the Properties object that scans a line
>read from a properties file for special escape sequences. I don't think
>that the Java source APIs are the be-all and end-all of code style, but
>it is a large public body of well-reviewed code. Note the abundant use
>of single character constants, with out a programmer introduced
>constant. It seems to read OK to me.

Likewise to me. It is short though so it does not prove much.
Were it a couple of pages long, it would be more of a test.

[snip]

Sincerely,

Gene Wirchenko

On 12/14/2012 12:26 PM, Gene Wirchenko wrote:

> I draw a line between things that are unlikely to change and
> those that may well change. Yes, I know that this is still blurry.

This is my point! The line *is* blurry! And I'm not sure if any hard
and fast rules can be made. Even generalities are somewhat hard to talk
about authoritatively.

(On 0, well n+0 is a bit gauche, yes? But I'll admit that things like
array indexes or sub-string offsets, yes 0 as a literal is allowed by
Oracles guidelines, and useful.)

>
> Likewise to me. It is short though so it does not prove much.
> Were it a couple of pages long, it would be more of a test.

The whole method is longer, and also broken up into three methods and
one private class. I think it's worth looking at. There was obviously
a deliberate effort to break-down the procedure into functional units,
which I think helps the readability of the code as much as anything.
(But also makes character literals more readable as a result.)

Unfortunately, the website with JDK source code isn't showing up on my
Google searches, so I can't make a link.

Arved Sandstrom <> writes:

> You missed Eric's point. You stipulated a rule - "final code does not need
> to have any strings literals. Strings should be always created via
> out-of-code resources". You just now broke your own rule with your

OK. How would you define the name of the file / database table /
whatever resource to hold the string literals? Would you always give it
as a command line parameter?

--
Jukka Lahtinen

On 12/14/2012 2:47 PM, markspace wrote:
> [...]
> I wonder, in general, where the line should be drawn? Java coding
> guidelines recommend that 1 and -1 can be used as literals, but other
> integer constants should defined as a "constant" by the programmer.

Java coding guidelines suggest -1,0,1 can be literals,
but only in `for' loops. Use them elsewhere, or use those
values in any type other than `int', and you're supposed
to use a `static final'. That is, the guidelines frown
on `q = 1.0 - p;' and even on `System.exit(0);'.

What utter nonsense!

Let's not forget that the Java coding guidelines come
from the same minds that made `byte' signed, invented
Integer#getInteger(String), and designed java.util.Date.
Consider the source.

--
Eric Sosman
d