Curious compiler warning

[Novice]

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);
}

 

[Lew]

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);
}

 

[Eric Sosman]

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(),

Pretty stupid method names.

Knew a guy once (this sounds crazy, but it's a true story) who
had a hard time inventing variable names. So he wrote himself a
little program to generate random names and printed out a sheet of
a few hundred such. Thereafter, any time he needed a variable name
and was stuck for a good idea he'd just grab his printout and take
the next random name -- crossing it off so as not to re-use it and
create confusion. Result: No one could read his code, not even he.

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?

There's absolutely nothing wrong with it; Eclipse is acting
like a nervous maiden aunt, as usual.

Somewhere in Eclipse's configuration menus there might be a way
to tell it to stop worrying about monsters under the bed. (It'll
probably be on a menu whose color scheme is dark blue on jet black.)
All I can suggest is that you search for that menu, and hope against
hope that it actually exists.

If you can't find anti-anxiety medicine for Eclipse, consider
NetBeans.

 

[Lew]

Pretty stupid method names.

Knew a guy once (this sounds crazy, but it's a true story) who
had a hard time inventing variable names. So he wrote himself a
little program to generate random names and printed out a sheet of
a few hundred such. Thereafter, any time he needed a variable name
and was stuck for a good idea he'd just grab his printout and take
the next random name -- crossing it off so as not to re-use it and
create confusion. Result: No one could read his code, not even he.


There's absolutely nothing wrong with it; Eclipse is acting
like a nervous maiden aunt, as usual.

No, there is something wrong with it. It's a wasted assignment

Somewhere in Eclipse's configuration menus there might be a way
to tell it to stop worrying about monsters under the bed. (It'll
probably be on a menu whose color scheme is dark blue on jet black.)
All I can suggest is that you search for that menu, and hope against
hope that it actually exists.

If you can't find anti-anxiety medicine for Eclipse, consider
NetBeans.

You can tune the warning levels in Eclipse, including telling it not to fret
over assignments to parameters. Here, though, the question is what the heck
assigning to the variables accomplishes. The answer is "nothing useful" and
the OP should heed Eclipse's advice.

 

[glen herrmannsfeldt]

(snip)

(snip)

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

 

[Lew]

(snip)


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/inde.../compiler/ref-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.

 

[Novice]

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

How so? My original code says - in my opinion - "thank you very much for
the value but we need to adjust it a little by subtracting one, aside
from that, it's perfect". It's not like we're changing start to an
arbitrary value like 0 or 5 billion regardless of the original value. The
code in this class basically just does String functions to count the
number of occurrences of a string in another string but I'm assuming that
the user will consider the initial character of the string being searched
as '1' while Java's methods are all 0-based. I'm just subtracting one to
bring the user's view of the situation in line with Java's view.

I'm just wondering why the compiler is so offended by "start--"....

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);
}

Yes, I definitely like that better. Strangely enough, writing

bar(start--, finish--);

gives me the same warning as before, presumably for the same reason.

 

[Lew]

How so? My original code says - in my opinion - "thank you very much for
the value but we need to adjust it a little by subtracting one, aside
from that, it's perfect". It's not like we're changing start to an

Nope. It says, "Subtract one from the value, extract the old value, then
store the new value back in the variable."

If all you needed was to subtract one, as is the case here, you'd only
subtract one and not store the result back. It's the store back that is
superfluous.

arbitrary value like 0 or 5 billion regardless of the original value. The

A change is a change is a change. Why do you think that the new value has any
influence on that?

code in this class basically just does String functions to count the

Your example showed absolutely no 'String' functions.

number of occurrences of a string in another string but I'm assuming that
the user will consider the initial character of the string being searched
as '1' while Java's methods are all 0-based. I'm just subtracting one to
bring the user's view of the situation in line with Java's view.

The word "just" means "and nothing else". This is not true in your example.
Your example *also* does something else, superfluously stores the new value
back to the variable. It also superfluously extracts the old value from the
value and ignores it.

I'm just wondering why the compiler is so offended by "start--"....

That has been explained upthread. What remains unclear? We'll be happy to
fill in any missing details if you indicate what's missing.

Yes, I definitely like that better. Strangely enough, writing

bar(start--, finish--);

gives me the same warning as before, presumably for the same reason.

Yes, the warning is for the same reason, but that code will have a different
effect.

Let's say you call 'foo(7, 3)'. The first version will call 'bar(6, 2)' (in
effect). The second will call 'bar(7, 3)'.

Do you get the reason for the warning (which you also called an error, of
which I approve)?

 

[glen herrmannsfeldt]

(snip)

(snip, then I wrote)

Irrelevant. There's absolutely no value to storing the result because it
isn't reused.
(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

 

[glen herrmannsfeldt]

(snip)
(snip, someone wrote)

How so? My original code says - in my opinion - "thank you very much for
the value but we need to adjust it a little by subtracting one, aside
from that, it's perfect".

But, as previously noted, why not bar(start-1, finish-1)?

Now, if you are using the new values 10 times, or maybe even
just two, then it is more obvious to me.

It's not like we're changing start to an
arbitrary value like 0 or 5 billion regardless of the original value. The
code in this class basically just does String functions to count the
number of occurrences of a string in another string but I'm assuming that
the user will consider the initial character of the string being searched
as '1' while Java's methods are all 0-based. I'm just subtracting one to
bring the user's view of the situation in line with Java's view.

I'm just wondering why the compiler is so offended by "start--"....

Personally, there are a few things that I find compilers warning
about that bother me. In this case, there is a claim that the test
is optional, and that the default is off.

I wouldn't turn it on, but others might.

-- glen

 

[Lew]

(snip)


(snip, then I wrote)


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.

 

[Roedy Green]

I'm just wondering why the compiler is so offended by "start--"....

The compiler worries when you compute something and don't use the
result. If you had said bar( --start ) it would be happy since
the incremented start is passed to bar.

It thinks perhaps you forgot to use the result, on made a typo and
used the wrong variable. It figures you are addled in some way or you
would not be computing values you did not need. If you meant it fine,
that's why it is just a warning. There is no rule in Java you MUST
use every result.

 

[Arved Sandstrom]

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

 

[glen herrmannsfeldt]

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

 

[Lew]

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]

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.

 

[Stefan Ram]

Pretty stupid method names.

They are not only stupid. But »*oo« possible was
derived directly from indecent wording.
So, I consider usage of such names to be substandard
and rude when writing for an unknown audience.

When I have to use meaningless place holder names,
I use »alpha«, »beta«, »gamma«, »delta«, »epsilon«,
and so on.

 

[Gavino]

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

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.

But that would also apply to any local variables, and it's clearly not
considered poor style to assign to those.

The real engineering reason is surely just that method code is generally
easier to understand and maintain if the parameters are used as constants,
and not changed in the method body.

 

[Gavino]

The compiler worries when you compute something and don't use the
result. If you had said bar( --start ) it would be happy since
the incremented start is passed to bar.

No. This would produce the same warning.

It's nothing to do with not using the result - in the original example, the
result *was* used. It's simply that assigning to a method parameter value is
considered 'bad style', that's all.

 

[Lars Enderin]

2012-01-11 17:11, Stefan Ram skrev:

They are not only stupid. But »*oo« possible was
derived directly from indecent wording.
So, I consider usage of such names to be substandard
and rude when writing for an unknown audience.

Prissy. Foo, bar, baz are time-honoured dummy names.

When I have to use meaningless place holder names,
I use »alpha«, »beta«, »gamma«, »delta«, »epsilon«,
and so on.

Could you please stop using German quotes (»...«)?