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

#20435

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-18 06:34 -0400
Message-ID<vEXzs.27998$tG.2948@newsfe15.iad>
In reply to#20412
On 12/17/2012 10:13 PM, Peter Duniho wrote:
> 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
>
Pete, I know where you're coming from, but Eric more accurately captured 
the scenarios I was thinking of. Another example is the old-style and 
somewhat language-agnostic pseudocode

round(d*100.)/100.

for rounding to 2 decimal places (substitute other powers of ten for 
rounding to less or more decimal places). [*] Here there is no meaning 
for those constants other than TEN or a HUNDRED.

As for the 100 or 400, I was thinking for example of the Gregorian day 
to Julian day number formula 
(http://en.wikipedia.org/wiki/Julian_day#Converting_Julian_or_Gregorian_calendar_date_to_Julian_Day_Number). 
You can see how many constants are involved here, including 100 and 400.

I would use named constants for precisely ZERO (0) of these numbers. 
Mainly because the Java or Perl or C# version of the method for doing 
this conversion will have a descriptive name, I will have it commented 
and include a link to a decent explanation perhaps. If a programmer 
looks at the 365 or 100 or 400 in that complete formula and doesn't 
understand what the numbers mean then named constants won't help either 
- they have bigger problems.

My points are this:

(1) Sometimes numbers truly have no other name;

(2) Often there is context (naming, commenting, rest of the code) that 
makes it abundantly clear what a number is.

AHS

* Let's not get started on how this isn't exact rounding. It isn't, no, 
most of us understand that. But it's pretty decent and fairly 
language-agnostic and pretty accurate numerical rounding.

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

#20464

FromPeter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
Date2012-12-18 10:54 -0800
Message-ID<16v4yulqhdd19$.qhn9q6330idh$.dlg@40tude.net>
In reply to#20435
On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:

> Pete, I know where you're coming from, but Eric more accurately captured 
> the scenarios I was thinking of.

His examples are exceptions to the rule, not demonstrations of a good rule.

> Another example is the old-style and somewhat language-agnostic pseudocode
> 
> round(d*100.)/100.
> 
> for rounding to 2 decimal places (substitute other powers of ten for 
> rounding to less or more decimal places). [*] Here there is no meaning 
> for those constants other than TEN or a HUNDRED.

Writing code like that is silly. You should use a proper "round()" method
that takes as input the number of decimal places to use.

In either case, arguably the number of decimal places to round by should be
declared itself as a constant. Writing "100" by itself tells the reader of
the code nothing about why one is rounding to two decimal places, versus
some other number.  This is true whether you use a more descriptive, more
functional "round()" method or go with the "*100, /100" approach.

"Expressive code" means that the reader understands _why_ the code is
implemented the way it is, not just _how_.  A literal 100 by itself used in
rounding tells the reader only _how_.

All code always tells you _how_.  Only expressive code tells you _why_.

> As for the 100 or 400, I was thinking for example of the Gregorian day 
> to Julian day number formula 
> (http://en.wikipedia.org/wiki/Julian_day#Converting_Julian_or_Gregorian_calendar_date_to_Julian_Day_Number). 
> You can see how many constants are involved here, including 100 and 400.

And in every case, those constants are meaningless as literals.  Naming
them allows the code to self-document.

> I would use named constants for precisely ZERO (0) of these numbers. 
> Mainly because the Java or Perl or C# version of the method for doing 
> this conversion will have a descriptive name, I will have it commented 
> and include a link to a decent explanation perhaps.

Comments get lost, go out of date, etc.  Only the code is guaranteed to
remain, so it's always better to document using the code itself, rather
than external sources.

> If a programmer 
> looks at the 365 or 100 or 400 in that complete formula and doesn't 
> understand what the numbers mean then named constants won't help either 
> - they have bigger problems.

I think that's wrong.  You may argue that if the programmer cannot after
sufficient thought understand what the numbers mean, then there's a
problem.  But that's not the bar here.  The bar is for _rapid_, unambiguous
comprehension.  Names provide that while literal numbers do not.

Denigrating someone just because they didn't instantly understand what you
mean is wrong.  The only "bigger problem" such a person has is the problem
that they are having to read code written by someone who didn't feel like
making it expressive enough.

> My points are this:
> 
> (1) Sometimes numbers truly have no other name;

Wrong.  We aren't naming the _numbers_ themselves.  We are describing them
in a way that explains how and why they are used in the code.

Every number you could ever use has such a description that can be
incorporated as a name.  In some cases, we forego this, rather than
including things like "forLoopIncrementByOne".  As I said, exceptions do
exist.

But your rounding and calendar examples to me a clearly on the other side,
benefitting clearly from having named constants in the code rather than
just plain literals.

> (2) Often there is context (naming, commenting, rest of the code) that 
> makes it abundantly clear what a number is.

"Abundantly clear" is in the eye of the beholder.

Pete

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

#20479

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-18 18:57 -0400
Message-ID<hx6As.29492$eK6.22996@newsfe31.iad>
In reply to#20464
On 12/18/2012 02:54 PM, Peter Duniho wrote:
> On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:
>
>> Pete, I know where you're coming from, but Eric more accurately captured
>> the scenarios I was thinking of.
>
> His examples are exceptions to the rule, not demonstrations of a good rule.
>
>> Another example is the old-style and somewhat language-agnostic pseudocode
>>
>> round(d*100.)/100.
>>
>> for rounding to 2 decimal places (substitute other powers of ten for
>> rounding to less or more decimal places). [*] Here there is no meaning
>> for those constants other than TEN or a HUNDRED.
>
> Writing code like that is silly. You should use a proper "round()" method
> that takes as input the number of decimal places to use.

As "silly" as it may be, it's a known technique for rounding to a 
specified increment - see 
http://en.wikipedia.org/wiki/Rounding#Rounding_to_a_specified_increment.

I didn't trot out the technique as an endorsement, it's an example.

Forget how silly the technique is, give me a great constant name that 
replaces "100." in that formula.

> In either case, arguably the number of decimal places to round by should be
> declared itself as a constant. Writing "100" by itself tells the reader of
> the code nothing about why one is rounding to two decimal places, versus
> some other number.  This is true whether you use a more descriptive, more
> functional "round()" method or go with the "*100, /100" approach.

Here's a thought - maybe _why_ you are rounding to 2 decimal places is 
because you want to round to 2 decimal places. No reasonable named 
constant is going to tell you that business requirement #17 required 
that the rounding be the same as an existing Excel table from 
spreadsheet such-and-such.

I didn't just pull that out of a hat either - I've had to do exactly 
that the past few months. If you can come up with a named constant that 
doesn't look like a paragraph that can express motives like that, please 
trot out an example.

> "Expressive code" means that the reader understands _why_ the code is
> implemented the way it is, not just _how_.  A literal 100 by itself used in
> rounding tells the reader only _how_.
>
> All code always tells you _how_.  Only expressive code tells you _why_.
>
>> As for the 100 or 400, I was thinking for example of the Gregorian day
>> to Julian day number formula
>> (http://en.wikipedia.org/wiki/Julian_day#Converting_Julian_or_Gregorian_calendar_date_to_Julian_Day_Number).
>> You can see how many constants are involved here, including 100 and 400.
>
> And in every case, those constants are meaningless as literals.  Naming
> them allows the code to self-document.

We seriously differ here. Inside a short method with a proper name there 
is no way that those numbers are meaningless.

>> I would use named constants for precisely ZERO (0) of these numbers.
>> Mainly because the Java or Perl or C# version of the method for doing
>> this conversion will have a descriptive name, I will have it commented
>> and include a link to a decent explanation perhaps.
>
> Comments get lost, go out of date, etc.  Only the code is guaranteed to
> remain, so it's always better to document using the code itself, rather
> than external sources.

Try this one on for size - the method name is also code. For this 
example - Gregorian date to Julian day number, or the reverse case) - a 
fairly short and obvious method name very accurately describes what's 
being done. If the comments have been removed then a reasonably 
intelligent programmer should be able to Google the underlying algorithm.

If you're about to suggest that the method name could be mangled at some 
point then God help us - the same coder who does that may also rename 
your constants.

>> If a programmer
>> looks at the 365 or 100 or 400 in that complete formula and doesn't
>> understand what the numbers mean then named constants won't help either
>> - they have bigger problems.
>
> I think that's wrong.  You may argue that if the programmer cannot after
> sufficient thought understand what the numbers mean, then there's a
> problem.  But that's not the bar here.  The bar is for _rapid_, unambiguous
> comprehension.  Names provide that while literal numbers do not.

"Sufficient thought"? It's a _Gregorian date to Julian day number_ 
formula - how many seconds should it take a person to sort of get what 
most of the numbers stand for? Like 365 and 100 and 400?

For that matter, follow the first link I provided and look at 
http://en.wikipedia.org/wiki/Julian_day#Converting_Julian_or_Gregorian_calendar_date_to_Julian_Day_Number. 
Please give me a concise and sensible named constant for all 13 numbers 
involved in the formula.

Then tell me why it matters. 99 percent of programmers don't care what 
the exact meaning of each individual number is, and well over half won't 
get the math. And you think it's essential that each be a named constant?

> Denigrating someone just because they didn't instantly understand what you
> mean is wrong.  The only "bigger problem" such a person has is the problem
> that they are having to read code written by someone who didn't feel like
> making it expressive enough.

I believe in expressive. I think some of your philosophies, like this 
one here, actually make code harder to understand.

>> My points are this:
>>
>> (1) Sometimes numbers truly have no other name;
>
> Wrong.  We aren't naming the _numbers_ themselves.  We are describing them
> in a way that explains how and why they are used in the code.

I happen to believe there are plenty of examples where the context 
provided by the code using that number, including variable and method 
names, does a much better job.

Let me give you an example: the use of 31 in many functions for hashing 
strings. What are you going to nominate as a name for that particular 
number?

> Every number you could ever use has such a description that can be
> incorporated as a name.  In some cases, we forego this, rather than
> including things like "forLoopIncrementByOne".  As I said, exceptions do
> exist.
>
> But your rounding and calendar examples to me a clearly on the other side,
> benefitting clearly from having named constants in the code rather than
> just plain literals.
>
>> (2) Often there is context (naming, commenting, rest of the code) that
>> makes it abundantly clear what a number is.
>
> "Abundantly clear" is in the eye of the beholder.

Clearly so.

AHS

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

#20490

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2012-12-18 20:02 -0500
Message-ID<kar3md$gks$1@dont-email.me>
In reply to#20479
On 12/18/2012 5:57 PM, Arved Sandstrom wrote:
> [...]
> Let me give you an example: the use of 31 in many functions for hashing
> strings. What are you going to nominate as a name for that particular
> number?

     Not precisely what you asked for, and not even the value
that you asked for, and not in Java, but a colleague once found:

	#define HASHSIZE 51  /* a smallish prime */

You may cringe when you are ready, Gridley.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#20496

FromLew <lewbloch@gmail.com>
Date2012-12-18 17:13 -0800
Message-ID<bc25fed6-f8d8-44e7-8a8a-f739f95bc1c6@googlegroups.com>
In reply to#20490
Eric Sosman wrote:
> Arved Sandstrom wrote:
>> [...]
>> Let me give you an example: the use of 31 in many functions for hashing
>> strings. What are you going to nominate as a name for that particular
>> number?
> 
>      Not precisely what you asked for, and not even the value
> that you asked for, and not in Java, but a colleague once found:
> 
> 	#define HASHSIZE 51  /* a smallish prime */
> 
> You may cringe when you are ready, Gridley.

I wasn't ready, but the cringing happened perforce.

That is a definite candidate for The Daily WTF.

-- 
Lew

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

#20609

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 19:35 -0500
Message-ID<50d25d43$0$282$14726298@news.sunsite.dk>
In reply to#20479
On 12/18/2012 5:57 PM, Arved Sandstrom wrote:
> On 12/18/2012 02:54 PM, Peter Duniho wrote:
>> On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:
>>
>>> Pete, I know where you're coming from, but Eric more accurately captured
>>> the scenarios I was thinking of.
>>
>> His examples are exceptions to the rule, not demonstrations of a good
>> rule.
>>
>>> Another example is the old-style and somewhat language-agnostic
>>> pseudocode
>>>
>>> round(d*100.)/100.
>>>
>>> for rounding to 2 decimal places (substitute other powers of ten for
>>> rounding to less or more decimal places). [*] Here there is no meaning
>>> for those constants other than TEN or a HUNDRED.
>>
>> Writing code like that is silly. You should use a proper "round()" method
>> that takes as input the number of decimal places to use.
>
> As "silly" as it may be, it's a known technique for rounding to a
> specified increment - see
> http://en.wikipedia.org/wiki/Rounding#Rounding_to_a_specified_increment.
>
> I didn't trot out the technique as an endorsement, it's an example.
>
> Forget how silly the technique is, give me a great constant name that
> replaces "100." in that formula.
>
>> In either case, arguably the number of decimal places to round by
>> should be
>> declared itself as a constant. Writing "100" by itself tells the
>> reader of
>> the code nothing about why one is rounding to two decimal places, versus
>> some other number.  This is true whether you use a more descriptive, more
>> functional "round()" method or go with the "*100, /100" approach.
>
> Here's a thought - maybe _why_ you are rounding to 2 decimal places is
> because you want to round to 2 decimal places. No reasonable named
> constant is going to tell you that business requirement #17 required
> that the rounding be the same as an existing Excel table from
> spreadsheet such-and-such.
>
> I didn't just pull that out of a hat either - I've had to do exactly
> that the past few months. If you can come up with a named constant that
> doesn't look like a paragraph that can express motives like that, please
> trot out an example.

FACTOR_FOR_ROUNDING and document the business rule where the constant
is would be *a* way of doing it.

Arne

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

#20483

FromGene Wirchenko <genew@telus.net>
Date2012-12-18 15:12 -0800
Message-ID<ott1d81991otj6gncds9obpneicn08ri20@4ax.com>
In reply to#20464
On Tue, 18 Dec 2012 10:54:08 -0800, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

>On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:
>
>> Pete, I know where you're coming from, but Eric more accurately captured 
>> the scenarios I was thinking of.
>
>His examples are exceptions to the rule, not demonstrations of a good rule.
>
>> Another example is the old-style and somewhat language-agnostic pseudocode
>> 
>> round(d*100.)/100.
>> 
>> for rounding to 2 decimal places (substitute other powers of ten for 
>> rounding to less or more decimal places). [*] Here there is no meaning 
>> for those constants other than TEN or a HUNDRED.
>
>Writing code like that is silly. You should use a proper "round()" method
>that takes as input the number of decimal places to use.

     Why?  You are just going to have to raise 10 to the power of 2.
Not surprisingly, that is 100.

>In either case, arguably the number of decimal places to round by should be
>declared itself as a constant. Writing "100" by itself tells the reader of
>the code nothing about why one is rounding to two decimal places, versus
>some other number.  This is true whether you use a more descriptive, more
>functional "round()" method or go with the "*100, /100" approach.

     It is a common idiom.  Outside computing, multiplying by 100 by
moving the decimal point two places to the left is understood by many,
including elementary school children.

[snip]

Sincerely,

Gene Wirchenko

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

#20564

FromGene Wirchenko <genew@telus.net>
Date2012-12-19 10:00 -0800
Message-ID<8304d85078s7fptda9mirjdgrkn6t2rbv2@4ax.com>
In reply to#20483
On Tue, 18 Dec 2012 15:12:41 -0800, Gene Wirchenko <genew@telus.net>
wrote:

>On Tue, 18 Dec 2012 10:54:08 -0800, Peter Duniho
><NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>
>>On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:
>>
>>> Pete, I know where you're coming from, but Eric more accurately captured 
>>> the scenarios I was thinking of.
>>
>>His examples are exceptions to the rule, not demonstrations of a good rule.
>>
>>> Another example is the old-style and somewhat language-agnostic pseudocode
>>> 
>>> round(d*100.)/100.
>>> 
>>> for rounding to 2 decimal places (substitute other powers of ten for 
>>> rounding to less or more decimal places). [*] Here there is no meaning 
>>> for those constants other than TEN or a HUNDRED.
>>
>>Writing code like that is silly. You should use a proper "round()" method
>>that takes as input the number of decimal places to use.
>
>     Why?  You are just going to have to raise 10 to the power of 2.
>Not surprisingly, that is 100.
>
>>In either case, arguably the number of decimal places to round by should be
>>declared itself as a constant. Writing "100" by itself tells the reader of
>>the code nothing about why one is rounding to two decimal places, versus
>>some other number.  This is true whether you use a more descriptive, more
>>functional "round()" method or go with the "*100, /100" approach.
>
>     It is a common idiom.  Outside computing, multiplying by 100 by
>moving the decimal point two places to the left is understood by many,
>including elementary school children.

     I did not get this right.  It should be right and "right".  Move
the decimal point two places to the right.  It is still true about the
elementary school children.

Sincerely,

Gene Wirchenko

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

#20607

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 19:31 -0500
Message-ID<50d25c78$0$282$14726298@news.sunsite.dk>
In reply to#20464
On 12/18/2012 1:54 PM, Peter Duniho wrote:
> On Tue, 18 Dec 2012 06:34:02 -0400, Arved Sandstrom wrote:
>
>> Pete, I know where you're coming from, but Eric more accurately captured
>> the scenarios I was thinking of.
>
> His examples are exceptions to the rule, not demonstrations of a good rule.
>
>> Another example is the old-style and somewhat language-agnostic pseudocode
>>
>> round(d*100.)/100.
>>
>> for rounding to 2 decimal places (substitute other powers of ten for
>> rounding to less or more decimal places). [*] Here there is no meaning
>> for those constants other than TEN or a HUNDRED.
>
> Writing code like that is silly. You should use a proper "round()" method
> that takes as input the number of decimal places to use.

That only moves the problem.

But sometimes moving it brings it close to a method signature that
will document.

But it is not making the problem go away.

Arne

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

#20606

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 19:29 -0500
Message-ID<50d25c08$0$282$14726298@news.sunsite.dk>
In reply to#20435
On 12/18/2012 5:34 AM, Arved Sandstrom wrote:
> On 12/17/2012 10:13 PM, Peter Duniho wrote:
>> 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
>>
> Pete, I know where you're coming from, but Eric more accurately captured
> the scenarios I was thinking of. Another example is the old-style and
> somewhat language-agnostic pseudocode
>
> round(d*100.)/100.
>
> for rounding to 2 decimal places (substitute other powers of ten for
> rounding to less or more decimal places). [*] Here there is no meaning
> for those constants other than TEN or a HUNDRED.

Really?

FACTOR_FOR_ROUNDING_TO_TWO_DECIMALS seems as a name to me.

If it was named FACTOR_FOR_ROUNDING it could even be changed to
accommodate other roundings that to 0.01.

I would never use the first.

I am not even sure that I would use the last, but the last
is not that bad.

Arne

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

#20611

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-19 20:44 -0400
Message-ID<ybtAs.23610$411.13683@newsfe02.iad>
In reply to#20606
On 12/19/2012 08:29 PM, Arne Vajhøj wrote:
> On 12/18/2012 5:34 AM, Arved Sandstrom wrote:
>> On 12/17/2012 10:13 PM, Peter Duniho wrote:
>>> 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
>>>
>> Pete, I know where you're coming from, but Eric more accurately captured
>> the scenarios I was thinking of. Another example is the old-style and
>> somewhat language-agnostic pseudocode
>>
>> round(d*100.)/100.
>>
>> for rounding to 2 decimal places (substitute other powers of ten for
>> rounding to less or more decimal places). [*] Here there is no meaning
>> for those constants other than TEN or a HUNDRED.
>
> Really?
>
> FACTOR_FOR_ROUNDING_TO_TWO_DECIMALS seems as a name to me.
>
> If it was named FACTOR_FOR_ROUNDING it could even be changed to
> accommodate other roundings that to 0.01.
>
> I would never use the first.
>
> I am not even sure that I would use the last, but the last
> is not that bad.
>
> Arne
>
If you absolutely had to have a name I suppose that's about as good as 
it gets. But assuming that you're using this technique you might in one 
spot want to round to 2 places, in another to 1 or 4 (not far-fetched 
actually), if you *are* using named constants I think you'd have to go 
with your first suggestion.

AHS

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

#20615

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 21:50 -0500
Message-ID<50d27cf0$0$294$14726298@news.sunsite.dk>
In reply to#20611
On 12/19/2012 7:44 PM, Arved Sandstrom wrote:
> On 12/19/2012 08:29 PM, Arne Vajhøj wrote:
>> On 12/18/2012 5:34 AM, Arved Sandstrom wrote:
>>> On 12/17/2012 10:13 PM, Peter Duniho wrote:
>>>> 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
>>>>
>>> Pete, I know where you're coming from, but Eric more accurately captured
>>> the scenarios I was thinking of. Another example is the old-style and
>>> somewhat language-agnostic pseudocode
>>>
>>> round(d*100.)/100.
>>>
>>> for rounding to 2 decimal places (substitute other powers of ten for
>>> rounding to less or more decimal places). [*] Here there is no meaning
>>> for those constants other than TEN or a HUNDRED.
>>
>> Really?
>>
>> FACTOR_FOR_ROUNDING_TO_TWO_DECIMALS seems as a name to me.
>>
>> If it was named FACTOR_FOR_ROUNDING it could even be changed to
>> accommodate other roundings that to 0.01.
>>
>> I would never use the first.
>>
>> I am not even sure that I would use the last, but the last
>> is not that bad.
>>
> If you absolutely had to have a name I suppose that's about as good as
> it gets. But assuming that you're using this technique you might in one
> spot want to round to 2 places, in another to 1 or 4 (not far-fetched
> actually), if you *are* using named constants I think you'd have to go
> with your first suggestion.

If one need to do multiple roundings, then multiple constants would
be needed.

The first is still not good.

The extended name should be related to the purpose not the factor
to handle the case where a rounding is changed for some calculations.

FACTOR_TO_ROUND_DOLLAR_AMOUNT
FACTOR_TO_ROUND_DISTANCE_MEASUREMENT
etc.

Arne

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

#20617

FromLew <lewbloch@gmail.com>
Date2012-12-19 23:15 -0800
Message-ID<d174faaf-a65f-4fa6-8ebb-338e5c9ea753@googlegroups.com>
In reply to#20615
Arne Vajhøj wrote:
> The extended name should be related to the purpose not the factor

This is best practice, and more consistently followed in proportion to experience in 
the field, I assess.

> to handle the case where a rounding is changed for some calculations.
> 
> FACTOR_TO_ROUND_DOLLAR_AMOUNT
> FACTOR_TO_ROUND_DISTANCE_MEASUREMENT
> etc.

These names serve your pedagogical purpose, but simultaneously serve to 
illustrate that there's an element of style involved, not just engineering.

To my eye those names are longer than need be. I cannot and will not claim any 
objective validity to that assessment, but I would in a project push for more elegant 
names.

I don't necessarily mean abbreviated. Elegance is an ineffable match of form to 
function to aesthetic expression. Sometimes terse, sometimes verbose, elegance 
adapts to the circumstance and objectives of the moment.

My preference in this instance for the proffered scenarios would be more like

DOLLAR_ROUNDER
DISTANCE_ROUNDER

My reasoning involves degree of information conveyed relative to length and subitizability
of morpheme count.

But my action is based on a more intuitive sense, arguably one that subsumes the 
rationalized basis.

-- 
Lew

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

#20622

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-20 06:00 -0400
Message-ID<nlBAs.10835$tK1.6323@newsfe07.iad>
In reply to#20615
On 12/19/2012 10:50 PM, Arne Vajhøj wrote:
> On 12/19/2012 7:44 PM, Arved Sandstrom wrote:
>> On 12/19/2012 08:29 PM, Arne Vajhøj wrote:
>>> On 12/18/2012 5:34 AM, Arved Sandstrom wrote:
>>>> On 12/17/2012 10:13 PM, Peter Duniho wrote:
>>>>> 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
>>>>>
>>>> Pete, I know where you're coming from, but Eric more accurately
>>>> captured
>>>> the scenarios I was thinking of. Another example is the old-style and
>>>> somewhat language-agnostic pseudocode
>>>>
>>>> round(d*100.)/100.
>>>>
>>>> for rounding to 2 decimal places (substitute other powers of ten for
>>>> rounding to less or more decimal places). [*] Here there is no meaning
>>>> for those constants other than TEN or a HUNDRED.
>>>
>>> Really?
>>>
>>> FACTOR_FOR_ROUNDING_TO_TWO_DECIMALS seems as a name to me.
>>>
>>> If it was named FACTOR_FOR_ROUNDING it could even be changed to
>>> accommodate other roundings that to 0.01.
>>>
>>> I would never use the first.
>>>
>>> I am not even sure that I would use the last, but the last
>>> is not that bad.
>>>
>> If you absolutely had to have a name I suppose that's about as good as
>> it gets. But assuming that you're using this technique you might in one
>> spot want to round to 2 places, in another to 1 or 4 (not far-fetched
>> actually), if you *are* using named constants I think you'd have to go
>> with your first suggestion.
>
> If one need to do multiple roundings, then multiple constants would
> be needed.
>
> The first is still not good.
>
> The extended name should be related to the purpose not the factor
> to handle the case where a rounding is changed for some calculations.
>
> FACTOR_TO_ROUND_DOLLAR_AMOUNT
> FACTOR_TO_ROUND_DISTANCE_MEASUREMENT
> etc.
>
> Arne
>
One of the points I am trying to get across, Arne, is that (1) you may 
not know any of that, or (2) there may be no higher purpose than an 
arbitrary choice.

As far as #2 goes, that was sort of my Excel spreadsheet scenario. This 
is from real modernization and integration work I'm doing - in various 
reports and spreadsheets that we are looking to replace, percentages may 
be displayed let's say to one or two places. There is no reason given 
for this choice, the raw numbers involved would support more places 
actually. Since these percentages are used in various Excel tables and 
charts for executive reporting, probably the *only* reason years and 
years ago is that so many decimal places looked "good".

This is not an unusual scenario: display rounding of numbers with no 
natural "right" number of decimal places. You can, say, go to 4 or 5 
places by significant digits. But the table or chart gets too busy, 
people object, so you round to 1 or 2 decimal places - for the decent 
reason of effective presentation of information.

AHS

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

#20629

FromGene Wirchenko <genew@telus.net>
Date2012-12-20 08:56 -0800
Message-ID<smg6d8dthqqi4vmcu6h9nse9qqukdpc5ob@4ax.com>
In reply to#20606
On Wed, 19 Dec 2012 19:29:58 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>FACTOR_FOR_ROUNDING_TO_TWO_DECIMALS seems as a name to me.
>
>If it was named FACTOR_FOR_ROUNDING it could even be changed to
>accommodate other roundings that to 0.01.
>
>I would never use the first.
>
>I am not even sure that I would use the last, but the last
>is not that bad.

     Both are rather long.  Get a few of them in a statement, and you
are probably looking at a second line (assuming an 80 or so character
limit).

     Names that are long can bloat statements horribly.

Sincerely,

Gene Wirchenko

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

#20608

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 19:33 -0500
Message-ID<50d25ccb$0$282$14726298@news.sunsite.dk>
In reply to#20435
On 12/18/2012 5:34 AM, Arved Sandstrom wrote:
> As for the 100 or 400, I was thinking for example of the Gregorian day
> to Julian day number formula
> (http://en.wikipedia.org/wiki/Julian_day#Converting_Julian_or_Gregorian_calendar_date_to_Julian_Day_Number).
> You can see how many constants are involved here, including 100 and 400.
>
> I would use named constants for precisely ZERO (0) of these numbers.
> Mainly because the Java or Perl or C# version of the method for doing
> this conversion will have a descriptive name, I will have it commented
> and include a link to a decent explanation perhaps.

Comments should be considered 2nd best to having it in the
code itself.

Arne

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

#20421

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-17 21:43 -0500
Message-ID<50cfd840$0$282$14726298@news.sunsite.dk>
In reply to#20406
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());

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

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

#20426

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-17 22:09 -0600
Message-ID<OK2dndFC1LAOcVLNnZ2dnUVZ8iOdnZ2d@giganews.com>
In reply to#20421
Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> 
> Which of these would you prefer:
> 
> A)
> 
> request.setWeight(1000 * response.getWeight());
> 
> B)
> 
> request.setWeight(MILLIGRAMS_PER_GRAM * response.getWeight());
> 
> C)
> 
> // convert from grams to milligrams
> request.setWeight(1000 * response.getWeight());
> 
> D)
> 
> request.setWeightInMilliGrams(1000 * response.getWeightInGrams());


E)

request.setMass( 1000 * response.getMass() );

:-p

-- 
Leif Roar Moldskred

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

#20504

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-18 20:59 -0500
Message-ID<50d11f84$0$287$14726298@news.sunsite.dk>
In reply to#20426
On 12/17/2012 11:09 PM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> Which of these would you prefer:
>>
>> A)
>>
>> request.setWeight(1000 * response.getWeight());
>>
>> B)
>>
>> request.setWeight(MILLIGRAMS_PER_GRAM * response.getWeight());
>>
>> C)
>>
>> // convert from grams to milligrams
>> request.setWeight(1000 * response.getWeight());
>>
>> D)
>>
>> request.setWeightInMilliGrams(1000 * response.getWeightInGrams());
>
>
> E)
>
> request.setMass( 1000 * response.getMass() );
>
> :-p

Somebody with a degree in physics?

:-)

Arne

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

#20439

From"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date2012-12-18 13:22 +0000
Message-ID<KIWdnQpzWr67803NnZ2dnUVZ8jmdnZ2d@bt.com>
In reply to#20421
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());

or better yet:

    request.setWeightInMg(convertGtoMg(response.getWeightInG());

(not that I like all these getter/setter methods, and, indeed, I suspect that 
in better designed code, a lot of the issue would not appear).

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

    -- chris

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

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