Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #20210 > unrolled thread
| Started by | bob smith <bob@coolfone.comze.com> |
|---|---|
| First post | 2012-12-10 08:22 -0800 |
| Last post | 2012-12-29 18:18 +0100 |
| Articles | 20 on this page of 146 — 22 participants |
Back to article view | Back to comp.lang.java.programmer
multi-line Strings bob smith <bob@coolfone.comze.com> - 2012-12-10 08:22 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 11:43 -0500
Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:36 -0800
Re: multi-line Strings markspace <-@.> - 2012-12-10 09:42 -0800
Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:51 -0800
Re: multi-line Strings markspace <-@.> - 2012-12-10 10:27 -0800
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 13:43 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 15:08 -0500
Re: multi-line Strings markspace <-@.> - 2012-12-10 13:05 -0800
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 16:22 -0500
Re: multi-line Strings markspace <-@.> - 2012-12-10 13:36 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 16:52 -0500
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 18:04 -0500
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 00:17 +0000
Re: multi-line Strings markspace <-@.> - 2012-12-10 17:35 -0800
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 01:56 +0000
Re: multi-line Strings markspace <-@.> - 2012-12-10 18:00 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:16 -0500
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:21 +0000
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:12 -0600
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-11 05:01 -0400
Re: multi-line Strings markspace <-@.> - 2012-12-11 09:46 -0800
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:26 +0000
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 16:25 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:10 -0500
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:31 +0000
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:30 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 03:35 -0600
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 11:54 +0000
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-15 08:53 -0500
Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-16 12:19 -0700
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:24 +0000
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:21 -0800
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 14:03 +0000
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:05 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:13 -0400
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:38 +0000
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 19:48 -0400
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 21:07 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-19 08:26 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 16:36 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 12:51 -0600
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 14:05 -0600
Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-15 18:22 +0100
Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 00:34 +0100
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 02:56 -0600
Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 14:07 +0100
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 13:44 -0600
Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-16 17:43 +0100
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:37 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:03 -0600
Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-11 10:43 -0600
Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:44 +0000
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:09 -0500
Re: multi-line Strings Sebastian <sebastian@undisclosed.invalid> - 2012-12-12 10:40 +0100
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-12 20:28 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 13:42 -0600
Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-11 07:58 +0100
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-11 10:08 -0500
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-11 09:41 -0600
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 15:02 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:27 -0500
Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-14 23:23 -0600
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 02:56 -0600
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-11 16:31 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 17:07 -0600
Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-11 15:31 -0800
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 19:41 -0600
Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-13 07:43 +0100
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 23:09 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-13 06:34 -0400
Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 07:35 +0100
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 02:44 -0600
Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:48 +0100
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:10 -0600
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-14 15:18 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:16 -0500
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-14 05:55 -0400
Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:50 +0100
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:12 -0600
Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-14 11:24 -0800
Re: multi-line Strings markspace <-@.> - 2012-12-14 11:47 -0800
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:26 -0800
Re: multi-line Strings markspace <-@.> - 2012-12-14 12:53 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:36 -0500
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 12:06 +0000
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:23 -0500
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-15 08:16 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:24 -0500
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:36 -0800
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:36 -0800
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:30 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:43 -0500
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-14 17:36 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:46 -0500
Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 04:29 -0600
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:45 -0400
Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 17:11 -0800
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 20:25 -0500
Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 18:13 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 06:34 -0400
Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-18 10:54 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 18:57 -0400
Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-18 20:02 -0500
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-18 17:13 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:35 -0500
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 15:12 -0800
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-19 10:00 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:31 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:29 -0500
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 20:44 -0400
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 21:50 -0500
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 23:15 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-20 06:00 -0400
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-20 08:56 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:33 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:43 -0500
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-17 22:09 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:59 -0500
Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:22 +0000
Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-18 07:52 -0600
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:58 -0500
Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:10 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:56 -0500
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:05 -0400
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:42 -0500
Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-17 22:18 -0700
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:46 -0500
Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 21:01 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:46 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:51 -0500
Re: multi-line Strings Patricia Shanahan <pats@acm.org> - 2012-12-17 19:41 -0800
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:19 -0400
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:50 -0500
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 05:23 -0400
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 13:25 -0800
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
Re: multi-line Strings Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-12-14 23:43 +0200
Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:20 -0500
Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:47 -0400
Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-12 08:33 -0700
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 11:32 -0800
Re: multi-line Strings markspace <-@.> - 2012-12-12 11:45 -0800
Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:33 -0800
Re: multi-line Strings Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-29 18:18 +0100
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-12-14 11:24 -0800 |
| Message-ID | <M1Lys.8038$fh5.476@newsfe26.iad> |
| In reply to | #20323 |
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.
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-12-14 11:47 -0800 |
| Message-ID | <kafvoc$jjp$1@dont-email.me> |
| In reply to | #20327 |
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++;
}
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2012-12-14 12:26 -0800 |
| Message-ID | <r72nc8du1poqqs4unvaq7nvqh19hmpnp37@4ax.com> |
| In reply to | #20328 |
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
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2012-12-14 12:53 -0800 |
| Message-ID | <kag3kq$chu$1@dont-email.me> |
| In reply to | #20329 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-14 22:36 -0500 |
| Message-ID | <50cbf02e$0$295$14726298@news.sunsite.dk> |
| In reply to | #20331 |
On 12/14/2012 3:53 PM, markspace wrote: > 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. The two main reasons to move literals to constants are: * safer change of value, because changing the constant changes it everywhere * better documentation by using a descriptive name I believe one would get a decent indication of whether to use a constant or not. Does the same literal occur more than once where it must be the same value? Would the code be more readable by using a descriptive name instead of a literal. There are still a bit of blur, but not so bad. Arne
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2012-12-15 12:06 +0000 |
| Message-ID | <pLqdnRV-9Y8A9FHNnZ2dnUVZ8vSdnZ2d@bt.com> |
| In reply to | #20344 |
Arne Vajhøj wrote:
> Does the same literal occur more than once where it must be the
> same value?
>
> Would the code be more readable by using a descriptive name
> instead of a literal.
This is all sound and very sensible.
But... I'm amused to note that these conditions also apply to identifiers used
in the code too. Say I have a class name MyClass, and methods
MyClass.myMethod(). It is obviously possible for the name "MyClass" to change,
similarly for methods (in fact -- for me -- class and method name changes are
the rule rather than the exception). So, in the spirit of this discussion,
shouldn't I put the class and method names into a config file somewhere (or
"meta-config") file, and only refer to the class and method via some sort of
access to the config data.
<class:122> something = new <class:122>();
something.<method:382365>(true);
;-)
-- chris
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-19 19:23 -0500 |
| Message-ID | <50d25a68$0$286$14726298@news.sunsite.dk> |
| In reply to | #20355 |
On 12/15/2012 7:06 AM, Chris Uppal wrote: > Arne Vajhøj wrote: > >> Does the same literal occur more than once where it must be the >> same value? >> >> Would the code be more readable by using a descriptive name >> instead of a literal. > > This is all sound and very sensible. > > But... I'm amused to note that these conditions also apply to identifiers used > in the code too. Say I have a class name MyClass, and methods > MyClass.myMethod(). It is obviously possible for the name "MyClass" to change, > similarly for methods (in fact -- for me -- class and method name changes are > the rule rather than the exception). So, in the spirit of this discussion, > shouldn't I put the class and method names into a config file somewhere (or > "meta-config") file, and only refer to the class and method via some sort of > access to the config data. > > <class:122> something = new <class:122>(); > something.<method:382365>(true); > > ;-) Funny. It would not make it more readable. It would make it less readable. And changing the name is not the same problem as changing a literal, because an inconsistent change will result in a compiler error. Arne
[toc] | [prev] | [next] | [standalone]
| From | Leif Roar Moldskred <leifm@dimnakorr.com> |
|---|---|
| Date | 2012-12-15 08:16 -0600 |
| Message-ID | <KOOdnU6nTaq5G1HNnZ2dnUVZ8oidnZ2d@giganews.com> |
| In reply to | #20344 |
Arne Vajhøj <arne@vajhoej.dk> wrote: > Does the same literal occur more than once where it must be the > same value? I like to add "for the same reason" to that check, just as a general warning against "factor cramming" (that is, when you cram together two factors of the program into one piece of code beacuse the factors are superficially similar even though they are different semantically or in nature.) -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-19 19:24 -0500 |
| Message-ID | <50d25aa5$0$286$14726298@news.sunsite.dk> |
| In reply to | #20360 |
On 12/15/2012 9:16 AM, Leif Roar Moldskred wrote: > Arne Vajhøj <arne@vajhoej.dk> wrote: > >> Does the same literal occur more than once where it must be the >> same value? > > I like to add "for the same reason" to that check, just as a general > warning against "factor cramming" (that is, when you cram together two > factors of the program into one piece of code beacuse the factors are > superficially similar even though they are different semantically or > in nature.) Yes. It has to same value by definition not just same value in current case. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2012-12-15 13:36 -0800 |
| Message-ID | <82049971-c05b-48bf-9a4b-8489279665e3@googlegroups.com> |
| In reply to | #20344 |
Arne Vajhøj wrote:
> The two main reasons to move literals to constants are:
> * safer change of value, because changing the constant changes it everywhere
> * better documentation by using a descriptive name
I would add a third - even though a constant be used but once, be it even
'private', its declaration up top as a constant variable can make it easier
to maintain over time.
So a constant like '0' doesn't really qualify by either of Arne's standards
nor by mine. But a constant like:
"precision mediump float;\n" +
"uniform sampler2D tex_sampler_0;\n" +
"uniform vec2 seed;\n" +
"uniform float stepsizeX;\n" +
"uniform float stepsizeY;\n" +
"uniform float stepsize;\n" + ...
is all too likely to change over time. Its burial deep in code as a
literal would make it hard to maintain, whereas its declaration as a
constant variable simplifies locating it for update, and improves
readability per Arne's second criterion.
> I believe one would get a decent indication of whether
> to use a constant or not.
Regardless of how you come down in one particular case or another,
the perspective that Arne suggests emphasizes readability and
maintainability. If you intelligently apply these principles you will
not err by much.
> Does the same literal occur more than once where it must be the
> same value?
>
> Would the code be more readable by using a descriptive name
> instead of a literal?
Would it be easier to maintain changes over time as a constant variable?
> There are still a bit of blur, but not so bad.
--
Lew
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2012-12-16 17:36 -0800 |
| Message-ID | <19tsc89kacvcg8acoq0cft7b5jaujhoro3@4ax.com> |
| In reply to | #20331 |
On Fri, 14 Dec 2012 12:53:43 -0800, markspace <-@.> wrote:
>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.
Quite. rec.arts.sf.written frequently has discussions,
sometimes heated, on the boundary between science fiction and fantasy
or, more generally, <genre1> and <genre2>.
>(On 0, well n+0 is a bit gauche, yes? But I'll admit that things like
Not necessarily, but almost certainly. (I might do it for
formatting or to make the point that I had considered what the value
should be were it at all in doubt. This is rather rare.)
>array indexes or sub-string offsets, yes 0 as a literal is allowed by
>Oracles guidelines, and useful.)
Or a sum variable's initialisation.
>> 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.)
I also try to keep my statements on one line unless it is
something like a long output statement or a procedure call where the
complexity is not there.
Several years ago, there was a post to, I think,
comp.lang.c.moderated where the OP asked how to optimise two
statements. I looked at them and did not see a way. Some time later,
someone posted a different version of the code.
The first version had long variable names, and each of the two
statements took two lines. The new version had shorter variable
names, and each statement fit on one line. The second version was
*much* more readable.
>Unfortunately, the website with JDK source code isn't showing up on my
>Google searches, so I can't make a link.
I will take your word for it. I can see how it would easily work
out as you stated.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2012-12-14 12:30 -0800 |
| Message-ID | <m23nc8lefgi25tvp5k2hdeuvscdd2sf293@4ax.com> |
| In reply to | #20328 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-14 22:43 -0500 |
| Message-ID | <50cbf1f2$0$294$14726298@news.sunsite.dk> |
| In reply to | #20330 |
On 12/14/2012 3:30 PM, Gene Wirchenko wrote: > 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? It should not be the value that decide that. The coding convention says: <quote> 10.3 Constants Numerical constants (literals) should not be coded directly, except for -1, 0, and 1, which can appear in a for loop as counter values. </quote> so -1, 0 amd 1 are all OK but *ONLY* in only in for loops. But it does not seem very well founded. > 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. That and documentation should be the main criteria. > 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. It should not even be constants. > If I were writing code dealing with weeks, I might well use 7 for > the number of days in a week. It depends on the context. It will obviously not change. But in some contexts NUMBER_DAYS_IN_WEEK will make it easier to understand the code than 7. > I draw another line between simple (where I am much less likely > to bother) and complex (where I am much more likely to). That seems to me to be a the readability rule. > 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. That is the change rule. > I draw a third line between temporary code and permanent code. > The former, unlikely; the latter, likely. Temporary code where best practices does not apply are not so interesting to discuss. Arne
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-14 17:36 -0500 |
| Message-ID | <kag9lq$heh$1@dont-email.me> |
| In reply to | #20328 |
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
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-12-14 22:46 -0500 |
| Message-ID | <50cbf27c$0$294$14726298@news.sunsite.dk> |
| In reply to | #20333 |
On 12/14/2012 5:36 PM, Eric Sosman wrote: > 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! It could probably have been done better. :-) > 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. Nobody is perfect. Arne
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-12-16 04:29 -0600 |
| Message-ID | <kak7ui$hf8$1@news.albasani.net> |
| In reply to | #20347 |
On 12/14/2012 9:46 PM, Arne Vajhøj wrote: > On 12/14/2012 5:36 PM, Eric Sosman wrote: >> 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! > > It could probably have been done better. > > :-) > yeah... better reason IMO to more follow the rule of "do what makes sense". like, adherence to rules for rules sake leads to all manner of absurdity. granted, yes, sometimes there are "bigger things" at stake by following or disregarding rules (like, moral ethics or the law), in which case, it is more a matter of "follow this rule, or bad things will result". actually, a little pet theory here is that "pretty much everything" mostly boils down to cost/benefit tradeoffs anyways... like, egoism + cost/benefit -> rules (both ethical and legal, as well as policies, practices, and conventions). a person may benefit mostly by following these rules (at least so far as they align with ones' benefit). not that not all rules are good though, many are instead the result of random peoples' opinions, and legalism... a good rule results from the inherent tradeoffs of a situation, and a bad rule results from "interpreting" statements based simply on what the words seem to saying (and all the stuff that goes with it: some people really liking their fine points of grammar and pulling out the dictionary to defend their arguments). (probably enough said here, don't need to wander off too far...). >> 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. > > Nobody is perfect. > and probably also JNI... but, yeah, unsigned byte makes more sense, and for a signed byte, there can be a type like, say: sbyte. then again, the lack of unsigned types in general is also a little annoying (and presumably it wouldn't have been *that* complicated to support them either, but whatever...). (the only notable difference at the VM level would likely have been needing to supply an unsigned divide operator somewhere...).
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2012-12-17 20:45 -0400 |
| Message-ID | <b1Pzs.16498$Id.11979@newsfe24.iad> |
| In reply to | #20328 |
On 12/14/2012 03:47 PM, 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. [ SNIP ] If I am multiplying by 2, or 10, or 1000, or using 100 or 400 when doing some forms of date conversions, almost all the time the context will make it clear what that constant is. If I were to religiously follow the coding guidelines, in no small number of cases I'd have to define constants that were called TWO or THOUSAND...which is sort of stupid. AHS
[toc] | [prev] | [next] | [standalone]
| From | Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> |
|---|---|
| Date | 2012-12-17 17:11 -0800 |
| Message-ID | <1rfmfoqs8bzc6.4pavkn8829dk$.dlg@40tude.net> |
| In reply to | #20403 |
On Mon, 17 Dec 2012 20:45:58 -0400, Arved Sandstrom 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. > [ SNIP ] > > If I am multiplying by 2, or 10, or 1000, or using 100 or 400 when doing > some forms of date conversions, almost all the time the context will > make it clear what that constant is. If I were to religiously follow the > coding guidelines, in no small number of cases I'd have to define > constants that were called TWO or THOUSAND...which is sort of stupid. Naming constants to be the same as the name of the value they represent, yes...that's stupid. But nothing about your example suggests that's actually how the constances should be named in the scenarios you describe. If you are multiplying by a constant, there's a reason. Often, for example, you are converting units (hours per day, days per week, etc., following your "date conversions" theme). The conversion itself is the correct name (e.g. "hoursPerDay", "daysPerWeek", etc.) in those examples. Similar logic can be applied to other values. There may be exceptions, to be sure. But I would say that the Java coding guidelines make lots of sense in this area. Values such as 0, 1, -1, and maybe even 2 in some cases generally are used in ways that are so clear as to obviate any need for a named constant. But pretty much any other value can benefit from a proper name, to allow the code to properly express for what purpose the value is being used. It's a pity...often the standard pedogogical justification for using named constants is so that you can change the value in one place, rather than having to go replace it everywhere in code. But this is faulty for at least two reasons: -- Even when the purpose is to make it easier to change a value, it's a VERY good idea to go visit every single place in the code that value is used, even when the value itself is being represented by a named constant. Having a named constant doesn't get you out of doing that. It just makes it simpler, because you don't have to visit places in the code the same numeric value is being used for some completely different purpose. -- The justification fails to convey the other very important reason for using named constants, which is to keep the code readable and, especially!, self-explanatory. A literal value might be plainly obvious to you, but not everyone reading the code is going to have the same view. Writing in words what the constant means, and using that in the code instead, ensures that the code as read actually explains what the code does. Pete
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-12-17 20:25 -0500 |
| Message-ID | <kaogn8$jkm$1@dont-email.me> |
| In reply to | #20405 |
On 12/17/2012 8:11 PM, Peter Duniho wrote: > On Mon, 17 Dec 2012 20:45:58 -0400, Arved Sandstrom 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. >> [ SNIP ] >> >> If I am multiplying by 2, or 10, or 1000, or using 100 or 400 when doing >> some forms of date conversions, almost all the time the context will >> make it clear what that constant is. If I were to religiously follow the >> coding guidelines, in no small number of cases I'd have to define >> constants that were called TWO or THOUSAND...which is sort of stupid. > > Naming constants to be the same as the name of the value they represent, > yes...that's stupid. > > But nothing about your example suggests that's actually how the constances > should be named in the scenarios you describe. > > If you are multiplying by a constant, there's a reason. Often, for example, > you are converting units (hours per day, days per week, etc., following > your "date conversions" theme). The conversion itself is the correct name > (e.g. "hoursPerDay", "daysPerWeek", etc.) in those examples. Similar logic > can be applied to other values. public static final int MILLIMETERS_PER_METER = 1000; public static final int MILLIGRAMS_PER_GRAM = 1000; public static final int MILLIAMPERES_PER_AMPERE = 1000; public static final int MILLISECONDS_PER_SECOND = 1000; Great aids to understanding, I'm sure. (And stop calling me Millie!) -- Eric Sosman esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> |
|---|---|
| Date | 2012-12-17 18:13 -0800 |
| Message-ID | <qdrd1mgseyq1$.1upmnl6v646ec$.dlg@40tude.net> |
| In reply to | #20406 |
On Mon, 17 Dec 2012 20:25:56 -0500, Eric Sosman wrote: > [...] >> If you are multiplying by a constant, there's a reason. Often, for example, >> you are converting units (hours per day, days per week, etc., following >> your "date conversions" theme). The conversion itself is the correct name >> (e.g. "hoursPerDay", "daysPerWeek", etc.) in those examples. Similar logic >> can be applied to other values. > > public static final int MILLIMETERS_PER_METER = 1000; > public static final int MILLIGRAMS_PER_GRAM = 1000; > public static final int MILLIAMPERES_PER_AMPERE = 1000; > public static final int MILLISECONDS_PER_SECOND = 1000; > > Great aids to understanding, I'm sure. (And stop calling me Millie!) I guess your intent is to be sarcastic. But personally, I think using a named constant does in fact make it clearer. I would not be a stickler for making those named constants, and of course have used literal values like those in code without naming them. But using them as a named constant would in fact make the code clearer. And of course, constants such as 100 or 400 (such as Arved mentioned) are even less obvious. As I said, there may be exceptions. SI units are notoriously easy to convert, so as long as your variables and methods are well-named (i.e. are clear about the units they represent), a named constant may not be called for when converting. So, fine...if you like, there's one of your exceptions. That doesn't take way from the more general validity of my comments. Pete
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web