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

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

Curious compiler warning

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

Contents

  Curious compiler warning Novice <novice@example..com> - 2012-01-11 01:51 +0000
    Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 18:10 -0800
      Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 02:36 +0000
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 19:03 -0800
          Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 07:50 +0000
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 23:57 -0800
          Re: Curious compiler warning Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-11 05:47 -0400
            Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 13:25 +0000
              Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 06:58 -0800
                Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 07:01 -0800
                Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-11 10:03 -0800
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 23:30 -0800
                Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:10 -0800
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-11 23:32 -0800
                    Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 01:44 -0600
                      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:42 -0800
                        Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 10:51 -0600
                      Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-12 07:50 -0800
                        Re: Curious compiler warning Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-01-12 10:54 -0600
                        Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
                    Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 11:51 -0800
                      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 20:58 -0800
          Re: Curious compiler warning "Gavino" <invalid@invalid.invalid> - 2012-01-11 20:05 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:47 -0800
          Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-21 12:13 -0800
      Re: Curious compiler warning Novice <novice@example..com> - 2012-01-11 04:55 +0000
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 21:46 -0800
        Re: Curious compiler warning glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-11 07:55 +0000
        Re: Curious compiler warning Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 01:35 -0800
          Re: Curious compiler warning "Gavino" <invalid@invalid.invalid> - 2012-01-11 20:05 +0100
            Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:18 -0800
              Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:55 -0800
                Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 11:59 -0800
              Re: Curious compiler warning Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-13 00:02 +0000
                Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-12 16:11 -0800
                  Re: Curious compiler warning Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-13 01:31 +0000
            Re: Curious compiler warning Roedy Green <see_website@mindprod.com.invalid> - 2012-01-11 18:26 -0800
              Re: Curious compiler warning Patricia Shanahan <pats@acm.org> - 2012-01-11 19:01 -0800
                Re: Curious compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-11 23:23 -0500
                  Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:00 -0800
              Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 07:50 -0800
          Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:14 -0800
            Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:05 -0800
              Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-12 12:02 -0800
    Re: Curious compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 21:11 -0500
      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-10 18:17 -0800
      Re: Curious compiler warning bugbear <bugbear@trim_papermule.co.uk_trim> - 2012-01-11 16:10 +0000
      Re: Curious compiler warning Lars Enderin <lars.enderin@telia.com> - 2012-01-11 20:45 +0100
        Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:09 -0800
        Re: Curious compiler warning Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-01-12 18:14 +0200
        Re: Curious compiler warning Wanja Gayk <brixomatic@yahoo.com> - 2012-01-21 12:52 +0100
        Re: Curious compiler warning David Lamb <dalamb@cs.queensu.ca> - 2012-01-21 09:12 -0500
      Re: Curious compiler warning Gene Wirchenko <genew@ocis.net> - 2012-01-11 18:21 -0800
      Re: Curious compiler warning Lew <noone@lewscanon.com> - 2012-01-12 08:08 -0800
    Re: Eclipse 3.7.1 compiler warning v_borchert@despammed.com (Volker Borchert) - 2012-01-11 21:10 +0000

Page 1 of 3  [1] 2 3  Next page →

#11201 — Curious compiler warning

I'm getting an odd compiler warning that I don't really understand. I 
wonder if anyone can enlighten me on the meaning of this message. 
Basically, I'm not sure what the compiler's problem is with what I'm doing 
or the best way to make it happy.

I've got a fairly simply method name foo() that takes two parameters, ints 
called start and finish. During this method, I decrement start and finish 
and then calls another method, bar(), passing the decremented versions of 
start and finish. For some reason, the compiler objects to the statements 
where I decrement start and finish and says "the parameter should not be 
assigned". I'm running Eclipse 3.7.1 with a 1.6.18 JDK. 

So here's what the code looks like:

public static int foo(int start, int finish) {

/* Other stuff */

  start--;
  finish--;

  bar(start, finish);  
}

It's the start--; and finish--; lines that are raising the warnings.

What exactly is wrong with doing that? And what is the best way to make the 
compiler happy about that code?

I modified the code as follows to get rid of the warnings but is it really 
necessary to create two local variables just to eliminate the warnings? Or 
is there a better way?

public static int foo(int start, int finish) {

/* Other stuff */

  int myStart = start;
  myStart--;
   
  int myFinish = finish;
  myFinish--;

  bar(myStart, myFinish);  
}



-- 
Novice

[toc] | [next] | [standalone]

#11206

On 01/10/2012 05:51 PM, Novice wrote:
> I'm getting an odd compiler warning that I don't really understand. I
> wonder if anyone can enlighten me on the meaning of this message.
> Basically, I'm not sure what the compiler's problem is with what I'm doing
> or the best way to make it happy.
>
> I've got a fairly simply method name foo() that takes two parameters, ints
> called start and finish. During this method, I decrement start and finish
> and then calls another method, bar(), passing the decremented versions of
> start and finish. For some reason, the compiler objects to the statements
> where I decrement start and finish and says "the parameter should not be
> assigned". I'm running Eclipse 3.7.1 with a 1.6.18 JDK.
>
> So here's what the code looks like:
>
> public static int foo(int start, int finish) {
>
> /* Other stuff */
>
>    start--;
>    finish--;
>
>    bar(start, finish);
> }
>
> It's the start--; and finish--; lines that are raising the warnings.
>
> What exactly is wrong with doing that? And what is the best way to make the
> compiler happy about that code?

What's exactly wrong is that the assignment to the parameters is thrown away, 
and does you no good.

> I modified the code as follows to get rid of the warnings but is it really
> necessary to create two local variables just to eliminate the warnings? Or
> is there a better way?
>
> public static int foo(int start, int finish) {
>
> /* Other stuff */
>
>    int myStart = start;
>    myStart--;
>
>    int myFinish = finish;
>    myFinish--;
>
>    bar(myStart, myFinish);
> }

Yes, there's a better way; that one is silly.

public static int foo(int start, int finish) {

/* Other stuff */

   bar(start - 1, finish - 1);
}

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11209

Lew <noone@lewscanon.com> wrote:

(snip)
>> I've got a fairly simply method name foo() that takes two parameters, ints
>> called start and finish. During this method, I decrement start and finish
>> and then calls another method, bar(), passing the decremented versions of
>> start and finish. For some reason, the compiler objects to the statements
>> where I decrement start and finish and says "the parameter should not be
>> assigned". I'm running Eclipse 3.7.1 with a 1.6.18 JDK.

(snip)
>>    start--;
>>    finish--;
>>    bar(start, finish);

> What's exactly wrong is that the assignment to the parameters 
> is thrown away, and does you no good.

Well, not thrown away until after the call to bar.

Does it actual notice that it isn't used other than
the call to bar?

How about:

   while(start+finish>0) {
      start--;
      finish--;
      bar(start, finish);
      }

Would it complain in that case?

(snip)

> Yes, there's a better way; that one is silly.
> public static int foo(int start, int finish) {

> /* Other stuff */
>   bar(start - 1, finish - 1);

That is probably what I would do, but maybe not in the
case of a more complicated loop.

-- glen

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

#11210

On 01/10/2012 06:36 PM, glen herrmannsfeldt wrote:
> Lew<noone@lewscanon.com>  wrote:
>
> (snip)
>>> I've got a fairly simply method name foo() that takes two parameters, ints
>>> called start and finish. During this method, I decrement start and finish
>>> and then calls another method, bar(), passing the decremented versions of
>>> start and finish. For some reason, the compiler objects to the statements
>>> where I decrement start and finish and says "the parameter should not be
>>> assigned". I'm running Eclipse 3.7.1 with a 1.6.18 JDK.
>
> (snip)
>>>     start--;
>>>     finish--;
>>>     bar(start, finish);
>
>> What's exactly wrong is that the assignment to the parameters
>> is thrown away, and does you no good.
>
> Well, not thrown away until after the call to bar.

Irrelevant.  There's absolutely no value to storing the result because it 
isn't reused.

> Does it actual notice that it isn't used other than
> the call to bar?
>
> How about:
>
>     while(start+finish>0) {
>        start--;
>        finish--;
>        bar(start, finish);
>        }
>
> Would it complain in that case?

Apples and oranges.  The OP's example didn't reuse the stored value.  And yes, 
Eclipse would complain (but only if you enable it to do so) because you are 
modifying a parameter, which is what the warning cares about.  You could 
justify it perhaps in this case because you are using the new value, unlike in 
the OP's example.  But then that's a different scenario, so not relevant here.

And why does everyone insist on putting autodecrement on a separate line anyway?

My Eclipse instance was not configured out of the box to report this warning. 
  So I turned the warning on.  (Which the OP must have done, eh?  Begging the 
question of why if they hate the feature so much.)  You don't have to set it 
as an error, or even a warning if you don't like it.

I also found an explanation in the Eclipse help of all places for the warning:
"Parameter assignment
"Assigning a value to a parameter is generally considered poor style 
programming. When this option is enabled, the compiler will signal such 
scenario either as an error or a warning."
which you can get by the inbuilt help or online at
<http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htm>

It's really a good idea to reach for product documentation (and Google) when 
you have such a question.  I think there are a lot of programmers who 
foolishly fail to read the docs.  We're talking fundamental user guide stuff 
here, not weird little corner facts.

Notice that they point out that it's considered poor style.  The engineering 
reason behind this is that parameter assignment goes away at the end of the 
method block.

In the OP's example the other reason is that the assignment is unnecessary; it 
doesn't help anything and increases code complexity, making it a bad idea.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11217

Lew <noone@lewscanon.com> wrote:

(snip)

>> (snip)
>>>>     start--;
>>>>     finish--;
>>>>     bar(start, finish);
>>

(snip, then I wrote)
>> Well, not thrown away until after the call to bar.

> Irrelevant.  There's absolutely no value to storing the result because it 
> isn't reused.

>> Does it actual notice that it isn't used other than the call to bar?

(snip)
> Apples and oranges.  The OP's example didn't reuse the stored value.  
> And yes, Eclipse would complain (but only if you enable it to do so) 
> because you are modifying a parameter, which is what the warning 
> cares about.  

One of the advantages of call by value is that you can use the parameter
as a variable, and change it when needed. 

> You could justify it perhaps in this case because you are using 
> the new value, unlike in the OP's example.  But then that's 
> a different scenario, so not relevant here.

> And why does everyone insist on putting autodecrement on a 
> separate line anyway?

It helps avoid the problem of using two on the same line.  

At least in C, you shouldn't do things like:

 x=y[i++]+y[i++];

I will guess that it isn't a good idea in Java, either.
I wouldn't always put one on a separate line, but sometimes the
extra readability is worth one or two lines.

> My Eclipse instance was not configured out of the box to report 
> this warning. So I turned the warning on.  (Which the OP must have 
> done, eh?  

I would probably only do it in small methods, where it is obvious
that it is used one place. For larger ones, it is too easy to forget,
and then want to use the original value sometime later.

> Begging the question of why if they hate the feature so much.)  
> You don't have to set it as an error, or even a warning if you 
> don't like it.

(snip)

> Notice that they point out that it's considered poor style.  The engineering 
> reason behind this is that parameter assignment goes away at the end of the 
> method block.

Well, in call by reference languages you have to be careful that you 
don't change something in the calling routine. It is an advantage of
call by value that you can change it because the change goes away.

> In the OP's example the other reason is that the assignment is unnecessary; it 
> doesn't help anything and increases code complexity, making it a bad idea.

-- glen

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

#11219

On 01/10/2012 11:50 PM, glen herrmannsfeldt wrote:
> Lew<noone@lewscanon.com>  wrote:
>
> (snip)
>
>>> (snip)
>>>>>      start--;
>>>>>      finish--;
>>>>>      bar(start, finish);
>>>
>
> (snip, then I wrote)
>>> Well, not thrown away until after the call to bar.
>
>> Irrelevant.  There's absolutely no value to storing the result because it
>> isn't reused.
>
>>> Does it actual notice that it isn't used other than the call to bar?
>
> (snip)
>> Apples and oranges.  The OP's example didn't reuse the stored value.
>> And yes, Eclipse would complain (but only if you enable it to do so)
>> because you are modifying a parameter, which is what the warning
>> cares about.
>
> One of the advantages of call by value is that you can use the parameter
> as a variable, and change it when needed.

All right.  A bit elliptical perhaps.  What are others, if that's "one of" them?

My comments about the OP's code were not to excoriate writing to parameters, 
but to excoriate writing to any variable to no purpose.

>> You could justify it perhaps in this case because you are using
>> the new value, unlike in the OP's example.  But then that's
>> a different scenario, so not relevant here.
>
>> And why does everyone insist on putting autodecrement on a
>> separate line anyway?
>
> It helps avoid the problem of using two on the same line.
>
> At least in C, you shouldn't do things like:
>
>   x=y[i++]+y[i++];
>
> I will guess that it isn't a good idea in Java, either.

Why isn't it a good idea in Java?

You may be right, but I'm curious why you think so.  The reasons would not be 
the same as for C, where the results are not well defined, since Java 
precisely defines the rules for such an expression.

> I wouldn't always put one on a separate line, but sometimes the
> extra readability is worth one or two lines.

Wha...?  The idioms in question were not two decrements of the same variable 
but one each of two different variables.

Take note of what you cited in your reply:
  start--;
  finish--;
  bar(start, finish);

Your comments are not germane to that case.

  bar(--start, --finish);

is just fine if you're going to reuse the stored decremented value.  But not 
if you're not.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11223

On 12-01-10 11:03 PM, Lew wrote:
[ SNIP ]
> 
> And why does everyone insist on putting autodecrement on a separate line
> anyway?
[ SNIP ]

Lew, I do just this pretty routinely these days. All of the short forms,
actually, not just -- and ++. About the only place where I normally
leave them is in "for" control expressions; more often than not with
"while" and "do" loops I'll keep the modification of "index" variables
with incrementing/decrementing etc also in separate statements, clearly
commented if necessary, in the body of the loop.

You won't catch me doing things like

values[--i]

or

b = (a += 3)

even.

The reason I don't do anything like this anymore is because it's not
just my code. And I've noted over the years that constructs like this
lead to defects. That's real life. People miss a nuance about when some
value is being modified, or even fail to note that it _is_ being
modified. Keeping the short-for operation on a separate line highlights
the fact that it is a modification.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11225

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
> On 12-01-10 11:03 PM, Lew wrote:
>> And why does everyone insist on putting autodecrement on a separate line
>> anyway?
> [ SNIP ]

> Lew, I do just this pretty routinely these days. All of the short forms,
> actually, not just -- and ++. About the only place where I normally
> leave them is in "for" control expressions; more often than not with
> "while" and "do" loops I'll keep the modification of "index" variables
> with incrementing/decrementing etc also in separate statements, clearly
> commented if necessary, in the body of the loop.

I agree. Write to make something readable, minimizing the thinking
required to read and understand it.

Now, there is the old C favorite:

   while(*s++ = *t++) ;

and that might be the only statement in the routine, in which case it
is pretty hard to miss.

For a single statement loop, and if it fits, with indending, in much
less than an 80 column line, then I might keep it all in one line.

If a loop loops better on separate lines, and it doesn't otherwise
complicate things, increment and decrement look nicer on 
separate lines.

> You won't catch me doing things like

> values[--i]

> or

> b = (a += 3)

> even.

> The reason I don't do anything like this anymore is because it's not
> just my code. And I've noted over the years that constructs like this
> lead to defects. That's real life. People miss a nuance about when some
> value is being modified, or even fail to note that it _is_ being
> modified. Keeping the short-for operation on a separate line highlights
> the fact that it is a modification.

Sometimes you just have to consider each case, how it affects
the readability. 

-- glen

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

#11226

On 01/11/2012 05:25 AM, glen herrmannsfeldt wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  wrote:
>> On 12-01-10 11:03 PM, Lew wrote:
>>> And why does everyone insist on putting autodecrement on a separate line
>>> anyway?
>> [ SNIP ]
>
>> Lew, I do just this pretty routinely these days. All of the short forms,
>> actually, not just -- and ++. About the only place where I normally
>> leave them is in "for" control expressions; more often than not with
>> "while" and "do" loops I'll keep the modification of "index" variables
>> with incrementing/decrementing etc also in separate statements, clearly
>> commented if necessary, in the body of the loop.
>
> I agree. Write to make something readable, minimizing the thinking
> required to read and understand it.
>
> Now, there is the old C favorite:
>
>     while(*s++ = *t++) ;
>
> and that might be the only statement in the routine, in which case it
> is pretty hard to miss.
>
> For a single statement loop, and if it fits, with indending, in much
> less than an 80 column line, then I might keep it all in one line.
>
> If a loop loops better on separate lines, and it doesn't otherwise
> complicate things, increment and decrement look nicer on
> separate lines.
>
>> You won't catch me doing things like
>
>> values[--i]
>
>> or
>
>> b = (a += 3)
>
>> even.
>
>> The reason I don't do anything like this anymore is because it's not
>> just my code. And I've noted over the years that constructs like this
>> lead to defects. That's real life. People miss a nuance about when some
>> value is being modified, or even fail to note that it _is_ being
>> modified. Keeping the short-for operation on a separate line highlights
>> the fact that it is a modification.
>
> Sometimes you just have to consider each case, how it affects
> the readability.

"Readability" is such a subjective term.  Someone who knows C, C++, C#, Java 
or certain other languages might find 'x[i++] = y[j++]" perfectly readable. 
Someone not familiar with these programming languages might not.

If your observation that such expressions has any evidence to back it up it's 
a good argument for something.  Maybe not for changing the potency of the 
auto-inc/decrement operator but for hiring better-trained programmers, but for 
something.  Assuming the evidence sustains the observation.

If you have a hard time understanding that expression and you call yourself a 
Java programmer, there's a disconnect.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11227

Lew wrote:
> If your observation that such expressions
cause defects
> has any evidence to back it up it's
> a good argument for something. Maybe not for changing the potency of the
> auto-inc/decrement operator but for hiring better-trained programmers, but for
> something. Assuming the evidence sustains the observation.
>
> If you have a hard time understanding that expression and you call yourself a
> Java programmer, there's a disconnect.
>


-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11232

On 1/11/2012 6:58 AM, Lew wrote:
...
> "Readability" is such a subjective term. Someone who knows C, C++, C#,
> Java or certain other languages might find 'x[i++] = y[j++]" perfectly
> readable. Someone not familiar with these programming languages might not.

I am familiar with C and C++. In the case of C, I've led a compiler
implementation project. I fully understand that expression.

It seems less obvious to me than it would written out as three
statements. Just as I like methods with a single clear purpose, I prefer
statements that have a single clear purpose such as "copy an element
from y to x", or "increment i".


> If your observation that such expressions has any evidence to back it up
> it's a good argument for something. Maybe not for changing the potency
> of the auto-inc/decrement operator but for hiring better-trained
> programmers, but for something. Assuming the evidence sustains the
> observation.
>
> If you have a hard time understanding that expression and you call
> yourself a Java programmer, there's a disconnect.
>

Fortunately, I don't care about being a Java programmer, or a C
programmer, or any other qualified sort of programmer. I'm just a
programmer. For my purposes, writing simple, obvious code in whatever
language I happen to be using is far more important than showing off my
understanding of the JLS.

The JLS itself agrees with me on this: "It is recommended that code not
rely crucially on this specification. Code is usually clearer when each
expression contains at most one side effect, as its outermost operation,
and when code does not depend on exactly which exception arises as a
consequence of the left-to-right evaluation of expressions."

[http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7]

The block:
{
   x[i] = y[i];
   i++;
   j++;
}

follows that recommendation. Squishing all three side effects into one
statement does not.

I would go against a JLS recommendation about how to use the language
only if I had a strong positive reason to do so. That is especially the
case when it is arguing for simplicity, which I would prefer anyway.

Patricia

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

#11260

On 01/11/2012 10:03 AM, Patricia Shanahan wrote:
> On 1/11/2012 6:58 AM, Lew wrote:
> ...
>> "Readability" is such a subjective term. Someone who knows C, C++, C#,
>> Java or certain other languages might find 'x[i++] = y[j++]" perfectly
>> readable. Someone not familiar with these programming languages might not.
>
> I am familiar with C and C++. In the case of C, I've led a compiler
> implementation project. I fully understand that expression.
>
> It seems less obvious to me than it would written out as three
> statements. Just as I like methods with a single clear purpose, I prefer
> statements that have a single clear purpose such as "copy an element
> from y to x", or "increment i".

Good point.

>> If your observation that such expressions has any evidence to back it up
>> it's a good argument for something. Maybe not for changing the potency
>> of the auto-inc/decrement operator but for hiring better-trained
>> programmers, but for something. Assuming the evidence sustains the
>> observation.
>>
>> If you have a hard time understanding that expression and you call
>> yourself a Java programmer, there's a disconnect.
>>
>
> Fortunately, I don't care about being a Java programmer, or a C
> programmer, or any other qualified sort of programmer. I'm just a
> programmer. For my purposes, writing simple, obvious code in whatever
> language I happen to be using is far more important than showing off my
> understanding of the JLS.
>
> The JLS itself agrees with me on this: "It is recommended that code not
> rely crucially on this specification. Code is usually clearer when each
> expression contains at most one side effect, as its outermost operation,
> and when code does not depend on exactly which exception arises as a
> consequence of the left-to-right evaluation of expressions."
>
> [http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7]
>
> The block:
> {
> x[i] = y[i];
> i++;
> j++;
> }
>
> follows that recommendation. Squishing all three side effects into one
> statement does not.
>
> I would go against a JLS recommendation about how to use the language
> only if I had a strong positive reason to do so. That is especially the
> case when it is arguing for simplicity, which I would prefer anyway.

Well, they're not so much talking about how to use the language as about 
programming style generally, so it's not normative, though it is good advice. 
  I just don't happen personally to agree that 'stuff[++index]' is all that 
difficult to comprehend or all that dangerous to use, but I'm also no opponent 
of verbosity in service of clarity.  So my question about why the 
autodecrement was on a separate line has been fully and usefully answered, and 
I encourage everyone to do so.

But if you aren't using the old value, please use the prefix form of the operator.

That autodecrement was used at all in the OP's example is still open to criticism.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11252

On Wed, 11 Jan 2012 06:58:10 -0800, Lew <noone@lewscanon.com> wrote:

[snip]

>If you have a hard time understanding that expression and you call yourself a 
>Java programmer, there's a disconnect.

     If I can not see what the expression means almost instantly, then
it is a candidate for simplification.

     I am not a fan of macho programming.

     Sometimes, we are tired.  Sometimes, we are in a hurry.
Sometimes, we are not so familiar with the code.  Why ask for trouble?
Do it obviously except when an exception to this is clearly warranted.

Sincerely,

Gene Wirchenko

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

#11261

On 01/11/2012 06:10 PM, Gene Wirchenko wrote:
> On Wed, 11 Jan 2012 06:58:10 -0800, Lew<noone@lewscanon.com>  wrote:
>
> [snip]
>
>> If you have a hard time understanding that expression and you call yourself a
>> Java programmer, there's a disconnect.
>
>       If I can not see what the expression means almost instantly, then
> it is a candidate for simplification.
>
>       I am not a fan of macho programming.
>
>       Sometimes, we are tired.  Sometimes, we are in a hurry.
> Sometimes, we are not so familiar with the code.  Why ask for trouble?
> Do it obviously except when an exception to this is clearly warranted.

While I agreed with Patricia's point, your points are sheer hyperbole.  We're 
talking about autoincrement and autodecrement, for Pete's sake!

Next you'll excoriate += as obscure.  Sheesh.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11262

Lew <noone@lewscanon.com> wrote:
 
> Next you'll excoriate += as obscure.  Sheesh.

Personally, I never use += and its brethren and I practically only use
autoincrement and -decrement in for loops. Not because I find them
obscure or hard to read, but because I find the long form either
equally or just slightly easier to read, so why use two different
syntactic constructs when a single one gets the job done just as well?

-- 
Leif Roar Moldskred

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

#11265

Leif Roar Moldskred wrote:
> Lew wrote:
>
>> Next you'll excoriate += as obscure.  Sheesh.
>
> Personally, I never use += and its brethren and I practically only use
> autoincrement and -decrement in for loops. Not because I find them
> obscure or hard to read, but because I find the long form either
> equally or just slightly easier to read, so why use two different
> syntactic constructs when a single one gets the job done just as well?

So I suppose you never use for-each, 'while' or 'do...while'?  You never use 
an anonymous class when a named one will do?  You won't use closures because 
SAMs will do, or vice versa?

Your little rule that you can only use one form of an expression is limiting 
and superstitious.  It is nice to see my pessimistic prediction so quickly 
validated.  Too many folks with ideas like yours here wind up as managers.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11277

Lew <noone@lewscanon.com> wrote:
 
> So I suppose you never use for-each, 'while' or 'do...while'?  You never use 
> an anonymous class when a named one will do?  You won't use closures because 
> SAMs will do, or vice versa?
> 
> Your little rule that you can only use one form of an expression is limiting 
> and superstitious.  It is nice to see my pessimistic prediction so quickly 
> validated.  Too many folks with ideas like yours here wind up as managers.

The key words in my post was really "just as well." Of course I use
for-each, while and do loops - because in them I see a benefit. I
don't see any benefit in +=, so I don't use it.- 

It's not a "rule" I have -- I have no problem with other people using
them and I'll use them if I ever come across a situation where there's
an advantage to them. So far, I haven't seen any reason to use
them. It's the same reason why I don't use octal notation in my Java
code.

-- 
Leif Roar Moldskred

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

#11268

On 1/11/2012 11:44 PM, Leif Roar Moldskred wrote:
> Lew<noone@lewscanon.com>  wrote:
>
>> Next you'll excoriate += as obscure.  Sheesh.
>
> Personally, I never use += and its brethren and I practically only use
> autoincrement and -decrement in for loops. Not because I find them
> obscure or hard to read, but because I find the long form either
> equally or just slightly easier to read, so why use two different
> syntactic constructs when a single one gets the job done just as well?
>

I regard a program both as communication from me to the compiler, and
from me to any programmer, myself included, who might read the program
in the future.

If my thought is "increment x", I prefer "++" because, of the available
ways of adding one to x, it most directly reflects my intent.

Patricia

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

#11278

Patricia Shanahan <pats@acm.org> wrote:
 
> If my thought is "increment x", I prefer "++" because, of the available
> ways of adding one to x, it most directly reflects my intent.

I'll buy that.. I find that I rarely increment variables outside of
for loops, though.

-- 
Leif Roar Moldskred

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

#11561

In article <ItydnQqFSvjEnJLSnZ2dnUVZ_gWdnZ2d@earthlink.com>, 
pats@acm.org says...

> If my thought is "increment x", I prefer "++" because, of the available
> ways of adding one to x, it most directly reflects my intent.

AOL!

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web