Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20210 > unrolled thread

multi-line Strings

Started bybob smith <bob@coolfone.comze.com>
First post2012-12-10 08:22 -0800
Last post2012-12-29 18:18 +0100
Articles 20 on this page of 146 — 22 participants

Back to article view | Back to comp.lang.java.programmer

Contents

  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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

#20442

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-18 07:52 -0600
Message-ID<Yt6dnQd3kZS_6E3NnZ2dnUVZ8nednZ2d@giganews.com>
In reply to#20439
Chris Uppal <chris.uppal@metagnostic.remove-this.org> wrote:

[SNIP]

> 
> Or just go the full OO hog:
> 
>    request.setWeight(response.getWeight());
> 
> And leave it to the Request, Response, and (in particular) the Weight classes 
> to sort out mutually convenient units and conversions themselves

A third option is to supply the unit as a separate argument:

  // Sets the mass to the given value in kilograms
  public void setMass( float massInKg ) { ... }

  // Sets the mass to the given value in the specified unit
  public void setMass( float value, Unit<Mass> inputUnit ) { 
    this.setMass( inputUnit.convertTo( value, Unit.KILOGRAM ) );
  }

  // Returns the value of the mass in kilograms
  public float getMass( ) { ... }
  
  // Returns the value of the mass in the specified unit
  public float getMass( Unit<Mass> outputUnit ) {
    return Unit.KILOGRAM.convertTo( this.getMass(), outputUnit );
  }

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#20503

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:58 -0500
Message-ID<50d11f36$0$287$14726298@news.sunsite.dk>
In reply to#20442
On 12/18/2012 8:52 AM, Leif Roar Moldskred wrote:
> Chris Uppal <chris.uppal@metagnostic.remove-this.org> wrote:
>
> [SNIP]
>
>>
>> Or just go the full OO hog:
>>
>>     request.setWeight(response.getWeight());
>>
>> And leave it to the Request, Response, and (in particular) the Weight classes
>> to sort out mutually convenient units and conversions themselves
>
> A third option is to supply the unit as a separate argument:
>
>    // Sets the mass to the given value in kilograms
>    public void setMass( float massInKg ) { ... }
>
>    // Sets the mass to the given value in the specified unit
>    public void setMass( float value, Unit<Mass> inputUnit ) {
>      this.setMass( inputUnit.convertTo( value, Unit.KILOGRAM ) );
>    }
>
>    // Returns the value of the mass in kilograms
>    public float getMass( ) { ... }
>
>    // Returns the value of the mass in the specified unit
>    public float getMass( Unit<Mass> outputUnit ) {
>      return Unit.KILOGRAM.convertTo( this.getMass(), outputUnit );
>    }

That is a very nice way.

And doing it that way in software controlling an airplane makes
sense to be.

But it may be quite a bit cumbersome in a typical XXX KLOC
business app.

Arne

[toc] | [prev] | [next] | [standalone]

#20452

FromGene Wirchenko <genew@telus.net>
Date2012-12-18 09:10 -0800
Message-ID<km81d85k33e4nu7vtu2cei4gqihg2scvne@4ax.com>
In reply to#20439
On Tue, 18 Dec 2012 13:22:42 -0000, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote:

[snip]

>or better yet:
>
>    request.setWeightInMg(convertGtoMg(response.getWeightInG());
                        ^^2                                 ^1 
     Capitalisation matters in SI.  1) "Mg" means megagrams.  2) S/B
"g".

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#20502

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:56 -0500
Message-ID<50d11ec0$0$287$14726298@news.sunsite.dk>
In reply to#20439
On 12/18/2012 8:22 AM, Chris Uppal wrote:
> Arne Vajhøj wrote:
>
>> B)
>>
>> request.setWeight(MILLIGRAMS_PER_GRAM * response.getWeight());
>
> While I'll grant that your (B) is OK, I'd point out that if you are mixing mg
> and g in the same program then you are already in a state of sin.
>
> Given that that might be necessary (and anyway sin is acceptable these days ;-)
> I'd want to be lot more explicit.
>
>      request.setWeightMg(1000 * response.getWeightG());

That was #D.

I do not like that due to the pollution of the method names.

> or better yet:
>
>      request.setWeightInMg(convertGtoMg(response.getWeightInG());

I still do not like the polluted set and get names.

But the conversion method is certainly a solution.

And the constant in that method may not require the named constants.

> Or just go the full OO hog:
>
>      request.setWeight(response.getWeight());
>
> And leave it to the Request, Response, and (in particular) the Weight classes
> to sort out mutually convenient units and conversions themselves

I don't think that would be very practical, because one of the classes
would have a method using a different unit than the rest of the class.

Arne

[toc] | [prev] | [next] | [standalone]

#20481

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-18 19:05 -0400
Message-ID<yE6As.16710$gf1.10192@newsfe14.iad>
In reply to#20421
On 12/17/2012 10:43 PM, Arne Vajhøj wrote:
> On 12/17/2012 8:25 PM, Eric Sosman wrote:
>> 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.
>
>
> Which of these would you prefer:
>
> A)
>
> request.setWeight(1000 * response.getWeight());
>
> B)
>
> request.setWeight(MILLIGRAMS_PER_GRAM * response.getWeight());
> field "weight" in the Response class is in grams, and that
> C)
>
> // convert from grams to milligrams
> request.setWeight(1000 * response.getWeight());
>
> D)
>
> request.setWeightInMilliGrams(1000 * response.getWeightInGrams());
>
> I don't think #B is that far fetched.
>
> Arne
>
Well, now that we are into units, strictly speaking I don't like any of 
the above. Unless you do something like F# with measures, there really 
isn't much to help you in a language like Java except rigorous 
discipline enforced through standards and reviews. Named constants won't 
help you, because how do you have a guarantee in B) that 
response.getWeight() is returning grams, and that request.setWeight() 
expects milligrams? All the named constant is ensuring is that you're 
multiplying by 1000, which the literal value of 1000 in the code would 
have done equally well.

AHS

[toc] | [prev] | [next] | [standalone]

#20499

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:42 -0500
Message-ID<50d11b6c$0$290$14726298@news.sunsite.dk>
In reply to#20481
On 12/18/2012 6:05 PM, Arved Sandstrom wrote:
> On 12/17/2012 10:43 PM, Arne Vajhøj wrote:
>> On 12/17/2012 8:25 PM, Eric Sosman wrote:
>>> 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.
>>
>>
>> Which of these would you prefer:
>>
>> A)
>>
>> request.setWeight(1000 * response.getWeight());
>>
>> B)
>>
>> request.setWeight(MILLIGRAMS_PER_GRAM * response.getWeight());
>> field "weight" in the Response class is in grams, and that
>> C)
>>
>> // convert from grams to milligrams
>> request.setWeight(1000 * response.getWeight());
>>
>> D)
>>
>> request.setWeightInMilliGrams(1000 * response.getWeightInGrams());
>>
>> I don't think #B is that far fetched.

> Well, now that we are into units, strictly speaking I don't like any of
> the above. Unless you do something like F# with measures, there really
> isn't much to help you in a language like Java except rigorous
> discipline enforced through standards and reviews. Named constants won't
> help you, because how do you have a guarantee in B) that
> response.getWeight() is returning grams, and that request.setWeight()
> expects milligrams? All the named constant is ensuring is that you're
> multiplying by 1000, which the literal value of 1000 in the code would
> have done equally well.

None of these methods prevent errors.

But some are easier to read-understand than others and some have
less side effect clutter.

Arne

[toc] | [prev] | [next] | [standalone]

#20430

FromJim Janney <jjanney@shell.xmission.com>
Date2012-12-17 22:18 -0700
Message-ID<ydna9tcey5a.fsf@shell.xmission.com>
In reply to#20406
Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> 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!)

public static final int MILLISECONDS_IN_24_HOURS = 1000 * 60 * 60 * 24;

One should not, of course, write MILLISECONDS_PER_DAY due to the
possibility of DST.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#20422

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-17 21:46 -0500
Message-ID<50cfd8ec$0$282$14726298@news.sunsite.dk>
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.
>
> 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 is not obvious to me that 1 is that different from 7 in relation to
readability.

> 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.

Simpler means fewer mistakes.

>    -- 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.

That one good argument exist should not be hold against another good
argument.

Arne

[toc] | [prev] | [next] | [standalone]

#20428

FromPeter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
Date2012-12-17 21:01 -0800
Message-ID<10xpq9ycibdcp$.3wdlfapigjxa$.dlg@40tude.net>
In reply to#20422
On Mon, 17 Dec 2012 21:46:02 -0500, Arne Vajhøj wrote:

> [...]
>> 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 is not obvious to me that 1 is that different from 7 in relation to
> readability.

You mean as literals?

I guess it depends on how 1 is being used.  There may even be self-evident
uses for the literal 7.  I just happen to think it probably occurs more
often (MUCH more often) with 1 than with 7.

> [...]
>>    -- 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.
> 
> That one good argument exist should not be hold against another good
> argument.

No, it shouldn't.  Sorry if what I wrote seemed to say it did.  I just feel
that when the concept is being taught, teachers often use the "just change
the value in one place" argument alone.  This fails to truly capture the
full importance of using named constants rather than literals, and at the
same time leads new programmers to incorrectly believe that it's always a
reasonable practice to go changing a named constant's value without then
visiting every place in the code that uses that named constant.

(In some cases, that's not required.  Small code base, coupled with a
straight-forward use of the named constant, can obviate the need to
double-check uses of the named constant.  But in any large code base,
especially in a team, there's always the possibility that some schmuck went
and wrote some code that depends on the specific value of the named
constant.  It's important to defend against that).

Pete

[toc] | [prev] | [next] | [standalone]

#20500

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:46 -0500
Message-ID<50d11c82$0$287$14726298@news.sunsite.dk>
In reply to#20428
On 12/18/2012 12:01 AM, Peter Duniho wrote:
> On Mon, 17 Dec 2012 21:46:02 -0500, Arne Vajhøj wrote:
>
>> [...]
>>> 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 is not obvious to me that 1 is that different from 7 in relation to
>> readability.
>
> You mean as literals?
>
> I guess it depends on how 1 is being used.  There may even be self-evident
> uses for the literal 7.  I just happen to think it probably occurs more
> often (MUCH more often) with 1 than with 7.
>
>> [...]
>>>     -- 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.
>>
>> That one good argument exist should not be hold against another good
>> argument.
>
> No, it shouldn't.  Sorry if what I wrote seemed to say it did.  I just feel
> that when the concept is being taught, teachers often use the "just change
> the value in one place" argument alone.  This fails to truly capture the
> full importance of using named constants rather than literals, and at the
> same time leads new programmers to incorrectly believe that it's always a
> reasonable practice to go changing a named constant's value without then
> visiting every place in the code that uses that named constant.
>
> (In some cases, that's not required.  Small code base, coupled with a
> straight-forward use of the named constant, can obviate the need to
> double-check uses of the named constant.  But in any large code base,
> especially in a team, there's always the possibility that some schmuck went
> and wrote some code that depends on the specific value of the named
> constant.  It's important to defend against that).

Very few practices completely prevent schmuk's doing something
bad.

It is good to review the code impacted by changing the value for
a constant.

Besides the risk of a schmuk not having used the constant, then
there are also other risks.

Like the new value being outside boundaries for which the
code is valid.

Arne

[toc] | [prev] | [next] | [standalone]

#20423

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-17 21:51 -0500
Message-ID<50cfda1c$0$287$14726298@news.sunsite.dk>
In reply to#20403
On 12/17/2012 7:45 PM, Arved Sandstrom wrote:
> 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.

It certainly is.

The benefits of the constants are:
* make it easy to change the value later all but only places where it should
* increase readability by acting as documentation

TWO fails to achieve any of those. It is far from given that all
constants of 2 must be changes. TWO does not tell any more than 2.

if(daysPaymentOverdue() > 2) {
    setAlarmLevel(2);
}

should not be converted to:

if(daysPaymentOverdue() > TWO) {
    setAlarmLevel(TWO);
}

but to:

if(daysPaymentOverdue() > NO_DAYS_TO_SET_ALARM) {
    setAlarmLevel(ALARM_NO_PAYMENT);
}

Arne

[toc] | [prev] | [next] | [standalone]

#20424

FromPatricia Shanahan <pats@acm.org>
Date2012-12-17 19:41 -0800
Message-ID<hridnRdP6eNYeFLNnZ2dnUVZ_vednZ2d@earthlink.com>
In reply to#20423
On 12/17/2012 6:51 PM, Arne Vajhøj wrote:
...
> TWO fails to achieve any of those. It is far from given that all
> constants of 2 must be changes. TWO does not tell any more than 2.
>
> if(daysPaymentOverdue() > 2) {
>     setAlarmLevel(2);
> }
>
> should not be converted to:
>
> if(daysPaymentOverdue() > TWO) {
>     setAlarmLevel(TWO);
> }
>
> but to:
>
> if(daysPaymentOverdue() > NO_DAYS_TO_SET_ALARM) {
>     setAlarmLevel(ALARM_NO_PAYMENT);
> }

I think a good test for deciding to name a constant is whether the
constant would have a better name than the number itself. It has nothing
to do with how big a number is, but with what it means.

For example, 2 in the Euclidean distance formula just means 2, and has
no better name. Similarly, 100 in the formula for calculating a
percentage is just 100.

On the other hand, each 2 in the example above does not just mean 2. It
is a number of days, or an alarm level, and can be given a more
meaningful name. If the example had used 1 instead of 2, I would still
agree with naming it.

Patricia

[toc] | [prev] | [next] | [standalone]

#20486

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-18 19:19 -0400
Message-ID<JR6As.11365$Ep5.7354@newsfe08.iad>
In reply to#20423
On 12/17/2012 10:51 PM, Arne Vajhøj wrote:
> On 12/17/2012 7:45 PM, Arved Sandstrom wrote:
>> 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.
>
> It certainly is.
>
> The benefits of the constants are:
> * make it easy to change the value later all but only places where it
> should
> * increase readability by acting as documentation
>
> TWO fails to achieve any of those. It is far from given that all
> constants of 2 must be changes. TWO does not tell any more than 2.
>
> if(daysPaymentOverdue() > 2) {
>     setAlarmLevel(2);
> }
>
> should not be converted to:
>
> if(daysPaymentOverdue() > TWO) {
>     setAlarmLevel(TWO);
> }
>
> but to:
>
> if(daysPaymentOverdue() > NO_DAYS_TO_SET_ALARM) {
>     setAlarmLevel(ALARM_NO_PAYMENT);
> }
>
> Arne
>
I agree, completely, because those are magic numbers.

My argument is expressed rather by this contrived example:

public int doubleInteger(int value) {
	return value * 2;
}

and I also trot out my rounding to an increment example again.

In a more meaningful sense, what I've also been trying to say is that - 
and I strongly believe that this is the case with the formula for 
Gregorian date to Julian day number conversion - that you gain nothing, 
and probably lose in readability, by trying to concoct named constants 
for all the literal numbers involved in any number of situations.

Let's take another almost absurd example, the volume of a sphere. Apart 
fro providing a named constant for pi, who is going to do that for the 4 
or the two 3's? Well, from the sounds of it Peter would, but who else?

Point being, for any number of algorithms the numbers are _not_ magic. 
They are documented formulae. If it is known what the formula is that is 
being expressed in code (including my simplistic "doubleInteger" 
method), it serves no purpose to supply named constants for the numeric 
literals. IMHO.

AHS

[toc] | [prev] | [next] | [standalone]

#20501

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:50 -0500
Message-ID<50d11d62$0$287$14726298@news.sunsite.dk>
In reply to#20486
On 12/18/2012 6:19 PM, Arved Sandstrom wrote:
> On 12/17/2012 10:51 PM, Arne Vajhøj wrote:
>> On 12/17/2012 7:45 PM, Arved Sandstrom wrote:
>>> 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.
>>
>> It certainly is.
>>
>> The benefits of the constants are:
>> * make it easy to change the value later all but only places where it
>> should
>> * increase readability by acting as documentation
>>
>> TWO fails to achieve any of those. It is far from given that all
>> constants of 2 must be changes. TWO does not tell any more than 2.
>>
>> if(daysPaymentOverdue() > 2) {
>>     setAlarmLevel(2);
>> }
>>
>> should not be converted to:
>>
>> if(daysPaymentOverdue() > TWO) {
>>     setAlarmLevel(TWO);
>> }
>>
>> but to:
>>
>> if(daysPaymentOverdue() > NO_DAYS_TO_SET_ALARM) {
>>     setAlarmLevel(ALARM_NO_PAYMENT);
>> }
>>
>> Arne
>>
> I agree, completely, because those are magic numbers.
>
> My argument is expressed rather by this contrived example:
>
> public int doubleInteger(int value) {
>      return value * 2;
> }
>
> and I also trot out my rounding to an increment example again.
>
> In a more meaningful sense, what I've also been trying to say is that -
> and I strongly believe that this is the case with the formula for
> Gregorian date to Julian day number conversion - that you gain nothing,
> and probably lose in readability, by trying to concoct named constants
> for all the literal numbers involved in any number of situations.
>
> Let's take another almost absurd example, the volume of a sphere. Apart
> fro providing a named constant for pi, who is going to do that for the 4
> or the two 3's? Well, from the sounds of it Peter would, but who else?
>
> Point being, for any number of algorithms the numbers are _not_ magic.
> They are documented formulae. If it is known what the formula is that is
> being expressed in code (including my simplistic "doubleInteger"
> method), it serves no purpose to supply named constants for the numeric
> literals.

It do happen that values are obvious in a given context and will never
have to be changed.

My experience though is that "obvious" varies quite a bit between
people, geographic locations, time etc..

So if there is just the slightest doubt, then I suggest using a
named constant.

The cost is very small and maybe it will benefit the maintenance
programmer sitting with the code in 15 years.

Arne

[toc] | [prev] | [next] | [standalone]

#20512

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-19 05:23 -0400
Message-ID<sIfAs.42140$LS5.14371@newsfe10.iad>
In reply to#20501
On 12/18/2012 09:50 PM, Arne Vajhøj wrote:
> On 12/18/2012 6:19 PM, Arved Sandstrom wrote:
[ SNIP ]
>>
>> Let's take another almost absurd example, the volume of a sphere. Apart
>> fro providing a named constant for pi, who is going to do that for the 4
>> or the two 3's? Well, from the sounds of it Peter would, but who else?
>>
>> Point being, for any number of algorithms the numbers are _not_ magic.
>> They are documented formulae. If it is known what the formula is that is
>> being expressed in code (including my simplistic "doubleInteger"
>> method), it serves no purpose to supply named constants for the numeric
>> literals.
>
> It do happen that values are obvious in a given context and will never
> have to be changed.
>
> My experience though is that "obvious" varies quite a bit between
> people, geographic locations, time etc..
>
> So if there is just the slightest doubt, then I suggest using a
> named constant.
>
> The cost is very small and maybe it will benefit the maintenance
> programmer sitting with the code in 15 years.
>
> Arne
>
Your suggestions - and indeed this is part of my overall argument - rely 
on the ability to supply a *good* named constant. I think we all of us 
would agree that that is important, just as it is for variable and 
method names.

What I am saying is that I believe there are plenty of situations where 
that is difficult (or nearly impossible) to do. And a lousy name for a 
named constant is worse than using the literal.

I'm actually a pretty reasonable guy. I pull strings out into XML config 
files and .properties files, and I've been known to use named constants 
for numeric literals too. I just don't do it when it makes no sense.

Nice point btw about being careful about changing the value of a named 
constant willy-nilly w/o inspecting all the usage sites, as it may break 
business rules.

AHS

[toc] | [prev] | [next] | [standalone]

#20594

FromLew <lewbloch@gmail.com>
Date2012-12-19 13:25 -0800
Message-ID<876cb8bb-ed4f-446a-918f-6f84cda6f53e@googlegroups.com>
In reply to#20512
Arved Sandstrom wrote:
> Nice point btw about being careful about changing the value of a named 
> constant willy-nilly w/o inspecting all the usage sites, as it may break 
> business rules.

That would depend on whether the clients recompile after the change.

It is quite conceivable to have a scenario where some artifacts still contain the 
old value of the constant while others the new.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20338

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-14 22:14 -0500
Message-ID<50cbeafd$0$291$14726298@news.sunsite.dk>
In reply to#20317
On 12/14/2012 1:35 AM, William Bonawentura wrote:
> There is good a "rule of life" :). Never create literals in the code.

As Eric has demonstrated that rule practically prevent writing a
lot of code.

Arne

[toc] | [prev] | [next] | [standalone]

#20339

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-14 22:14 -0500
Message-ID<50cbeb34$0$291$14726298@news.sunsite.dk>
In reply to#20317
On 12/14/2012 1: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.

Annotations are also code.

Arne

[toc] | [prev] | [next] | [standalone]

#20332

FromJukka Lahtinen <jtfjdehf@hotmail.com.invalid>
Date2012-12-14 23:43 +0200
Message-ID<lv7goktilc.fsf@saunalahti.fi>
In reply to#20290
Arved Sandstrom <asandstrom2@eastlink.ca> 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

[toc] | [prev] | [next] | [standalone]

#20341

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-14 22:20 -0500
Message-ID<50cbec88$0$291$14726298@news.sunsite.dk>
In reply to#20332
On 12/14/2012 4:43 PM, Jukka Lahtinen wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> 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?

I assume that question was not for Arved ...

Arne

[toc] | [prev] | [next] | [standalone]

Page 7 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