«

On Tue, 18 Dec 2012 10:54:08 -0800, 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.

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

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

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
d

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

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

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

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

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.getWei ghtInG());

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

On 12/18/2012 8:52 AM, Leif Roar Moldskred wrote:
> Chris Uppal <> 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

On 12/17/2012 11:09 PM, Leif Roar Moldskred wrote:
> Arne Vajhøj <> 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