Curious compiler warning

[Volker Borchert]

[ ... ] "the parameter should not be assigned". [ ... ]

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?

The casual reader might miss that bar() is being passed values different
from those having been passed to foo().

And what is the best way to make the
compiler happy about that code?

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

/* Other stuff */

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

 

[Gene Wirchenko]

[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

 

[Gene Wirchenko]

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.

So why does it not just suppress the corresponding object?

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.

But the compiler message is pushing it that way.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

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.

Oh, my. Bad style. That is bad, isn't it? I am wearing a dark
grey sweater and medium brown pants. Is anyone's compiler concerned
about my style?

"style" and "best practices" get bandied about as if they are
sacred. Often, they are merely someone's opinion, and not necessarily
a well-thought-out one either.

If a parameter is call-by-value, it is available for modification
in many languages. Such code is shorter, too. I prefer a concise
style.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

They are not only stupid. But »*oo« possible was
derived directly from indecent wording.

No, "foo" was not. Read "The New Hacker's Dictionary" (or
possibly, the jargon) for a discussion of this.

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.

All five terms have meanings. Alpha, beta, and gamma are types
of radiation. Delta and epsilon are terms used in mathematics.

Sincerely,

Gene Wirchenko

 

[Roedy Green]

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.

Normally I mark my parms final, but have modified them. I don't
recall ever seeing that warning. I guess it does not show up in
IntelliJ.

 

[Eric Sosman]

I believe the warning originally came from Eclipse. The Eclipse style
rules are not carved in stone. A programmer who does not agree with the
default settings should change them.

To my way of thinking, a method (or constructor) parameter is
nothing more nor less than a local variable, taking its initial
value from the caller's argument. One characteristic of a variable
is that it can vary; that's why we don't call them invariables. I
can see no reason to preserve a parameter's initial value in bronze
like Baby's first shoes, and Eclipse's assertion that failing to
bronze a parameter "is generally considered poor style" is merely
noise, Proof By Iterated Assertion. (In the passive voice, which
is generally considered poor style.)

If anyone, anywhere, anyhow, has evidence that bronzing the
parameters improves them, let the evidence (and not just the PBIA)
be produced. Until then, I'll leave my parameters unbronzed and
still wearable.

 

[Lew]

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 = y;
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]

[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]

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]

Lew wrote ...

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

Except that in the method block, the caller still has the arguments, whereas
in a local block the variable is not referenceable. That's the difference,
and the reason why the pundits recommend against parameter assignment. It's
too easy for programmers (presumably the same ones who have a problem with ++
and +=) might think they're in a pass-by-reference world and wonder what
happened to their "assignment" to the argument. That's not a risk with local
variables.

People asked for an explanation of the principle. This is an explanation. If
you want to say the rule shouldn't exist, you will get no argument from me,
but if you want to say the reason is bad you'll have to complain to those who
made the rule.

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.

That's not an engineering reason, that's a conclusion. For one thing, your
explanation doesn't even begin to counter your own objection. You must go deeper.

 

[Lew]

"Roedy Green" spewed ...

No. This would produce the same warning.

As earlier mentioned.

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.

In the original example, the result was not used. The side effect was used,
but superfluously because it didn't need to be stored to be used. The problem
wasn't that the target was a method parameter, in that particular instance,
but that an assignment was performed at all.

 

[Lew]

Oh, my. Bad style. That is bad, isn't it? I am wearing a dark
grey sweater and medium brown pants. Is anyone's compiler concerned
about my style?

"style" and "best practices" get bandied about as if they are
sacred. Often, they are merely someone's opinion, and not necessarily
a well-thought-out one either.

If a parameter is call-by-value, it is available for modification
in many languages. Such code is shorter, too. I prefer a concise
style.

Except perhaps for auto-inc/decrement and op-assignment?

When the pundits call these things "bad style", it's completely unrelated to
matters of personal taste. You are stalking a dead horse. They have
engineering reasons, in the case of the OP's complaint a perceived risk of
error from the idiom. It is the presence of such risk that makes the style
"bad". If you can objectively prove such risk exists, the style is bad. If
you can objectively prove it does not, the style is good. If you don't know,
you can claim one or the other as an hypothesis but not a theory.

So everyone who wants to minimize the risk of error in a program cares about
your style, and you should, too! People should feel free to write compilers
that support such criteria. Oh, hey! Eclipse did! And the issues that are
not proven to be bad style, but claimed by enough wise people to be, are
*options* to enforce in that compiler.

Dju better get chyo style toGETHah, yo!

 

[Lew]

Correct. This point does bear repeating.

To my way of thinking, a method (or constructor) parameter is
nothing more nor less than a local variable, taking its initial
value from the caller's argument. One characteristic of a variable
is that it can vary; that's why we don't call them invariables. I
can see no reason to preserve a parameter's initial value in bronze
like Baby's first shoes, and Eclipse's assertion that failing to
bronze a parameter "is generally considered poor style" is merely
noise, Proof By Iterated Assertion. (In the passive voice, which
is generally considered poor style.)

If anyone, anywhere, anyhow, has evidence that bronzing the
parameters improves them, let the evidence (and not just the PBIA)
be produced. Until then, I'll leave my parameters unbronzed and
still wearable.

+1

I don't often change parameter variables, but when I do there's a need to.
Certain algorithms can benefit from doing so, and I personally am so steeped
in Java's call-by-value world that I don't acknowledge the risk feared by
those who favor the rule. OTOH, it's almost never needed.

 

[Lew]

Novice wrote, quoted or indirectly quoted someone who said :

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

[where 'start' is a method parameter]

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, that's not true. The Eclipse warning about modifying a parameter has
nothing to do with use of the result. Please do not confuse the newbies.

So why does it not just suppress the corresponding object?

Red herring. The message is simply about assignment to a method parameter, in
this case, and has absolutely nothing at all whatsoever to do with forgetting
to use the result, or making a typo, or using the wrong variable. It is no
more useful to provide this kind of misinformation that it was for Lucy van
Pelt (in the /Peanuts/ cartoon strip) to tell her younger brother that
telephone poles were specially bred trees with short, stubby little branches.

But the compiler message is pushing it that way.

No, it isn't. The compiler message in this case is not "pushing" for
anything, least of all for using the results of an assignment. It is simply a
checkmark the OP set to warn (or error) if there is an assignment to a method
parameter. That's it. Period. Drop the myths, personifications and
superstitions.

 

[Lew]

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.

Wow, that carries prudishness to a whole new level.

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

That is reasonable, uncontroversial, and traditional. Good policy.

 

[Lew]

Stefan Ram skrev:

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

That seems petty.

 

[Jussi Piitulainen]

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


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

They are a smart thing to use to talk about Java code
because they do not look like Java code.

 

[Gene Wirchenko]

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

No, not hyperbole. Such a statement does two things. In a quick
or hurried look through code, it might get missed. I prefer that
statements do one thing.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Except perhaps for auto-inc/decrement and op-assignment?

No. I rarely have need of such things. I recognise that I could
miss something like that due to this. To decrease the risk, I avoid
it except where it is part of the idiom I use.

Trade-offs are rife in this industry. You have just found one of
mine. I am not one-dimensional in my concerns.

When the pundits call these things "bad style", it's completely unrelated to
matters of personal taste. You are stalking a dead horse. They have
engineering reasons, in the case of the OP's complaint a perceived risk of
error from the idiom. It is the presence of such risk that makes the style

They might. Sometimes, it is just someone's bias.

"bad". If you can objectively prove such risk exists, the style is bad. If
you can objectively prove it does not, the style is good. If you don't know,
you can claim one or the other as an hypothesis but not a theory.

If doing so creates another bigger risk, the style is bad.

So everyone who wants to minimize the risk of error in a program cares about
your style, and you should, too! People should feel free to write compilers
that support such criteria. Oh, hey! Eclipse did! And the issues that are
not proven to be bad style, but claimed by enough wise people to be, are
*options* to enforce in that compiler.

Wonderful. So to use such a compiler, I have to make sure to
configure it just right. Is there a confgiuration style that is
enforced?

Dju better get chyo style toGETHah, yo!

Not the usual style of this newsgroup to be sure.

Sincerely,

Gene Wirchenko