Curious compiler warning

[Gene Wirchenko]

Gene Wirchenko wrote:
[snip]

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.

How often have you read that compiler warnings should all be
looked at?

We have personification in English. It is useful to avoid
verbiage. I could have written the "pushing" statement without it,
but then the statement would have been much longer.

Sincerely,

Gene Wirchenko

 

[Martin Gregorie]

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?

IMO the only egregiously bad style is not sticking to the style used by
the original programmer when you're amending the program. In my book this
is an invariant rule, no matter how obnoxious the original style is
because doing anything else is sure-fire way to make even very ugly code
much worse.

 

[Martin Gregorie]

I agree. In a few cases, I've kept a shadow copy of some code that was
formatted with reasonable indentation etc. for reading, but still made
my changes in the original code, warts and all.

Very bad style (COBOL example - sorry)

- all data names took the form XXnn where, for instance MT01 was the
name of the first record in the first file declared and it went on
MT02, MT03, MT04... through the fields in that record and continued
in this fashion through all the fields in all the record definitions
in 3 or 4 files. Same for cards (from CD01), printers (from LP01) and
through working storage (WS01.....)

- Procedure division was similar: all paragraph names were of the form
GDnnnnn, were not in numeric sequence, and no sections were used.

....and this was a 5000 line program!

The same clowns had developed an entire accounting package this way,
except for a few programs which were written in equally obnoxious
assembler. That means assembler with almost no comments or labels and an
obsession with using register-register operations and relative jumps in
preference to named storage locations and jumps to labels.

To make matters worse, one of our idiot managers had bought the blasted
package without appraising either the code or the (almost non-existent)
documentation.

The third axiom of programming being "If a program is useful, it must be
modified", guess who got lumbered with that....

 

[Lew]

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.

The idea is good, that code should be clear. I should support your view
because it is motivated by the greater good and works more effectively in the
real world. I certainly would never support a code standard to prefer
conversion to the abbreviated form, nor fault the long form in a code review.
Your logic is compelling and conclusive. I reserve not to comment against the
short forms in a code review because a professional programmer should not be
so careless as to miss an op= or autoXcrement op. So I support the populist
view that reduces risk for overworked and frazzled workaday programmers and
cuts them some slack and the professional view that assumes fluency in the
basic idioms.

Thank you for a well-expressed and informative series of posts.

 

[David Lamb]

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

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

It's an international newsgroup; seems to me that those of us following
the "xxx" quote convention should learn a little flexibility.

 

[Lew]

My best guess is that the warning to "not assign the parameters" is
style-check warning, that just gives a hint on the best practice not to
assign values to the parameters of a method.

That is correct.

So maybe he's rather asking for some change like:

void foo(int x, int y){
x++;
...
}

to

void foo(int x, int y){
int start = x+1;
...
}

as solution to his warning.

That's a workaround, but as many in this thread have pointed out, there's
really nothing wrong with assigning to a parameter variable save that it
breaks the documentary connection to its parameter-ness. The Checkstyle
rationale cited /infra/ uses the same weasel-wording one typically encounters:
passive voice conditional "can be confusing", ducking the questions of to whom
and under what circumstances.

In the OP's case we've already discussed the option to disable this warning in
the Eclipse settings.

Checkstyle says:

"FinalParameters
Description

Check that method/constructor/catch block parameters are final.
Interface and abstract methods are not checked - the final keyword does
not make sense for interface and abstract method parameters as there is
no code that could modify the parameter.

Rationale: Changing the value of parameters during the execution of the
method's algorithm can be confusing and should be avoided. A great way
to let the Java compiler prevent this coding style is to declare
parameters final."

While Java rockstar Adam Bien says:

(Which I disagree on and I have made my point in the answers, which you
might like or not).

He also makes some factual errors. His example purporting to require the
'final' keyword would have worked if the anonymous class referred to the outer
class member instead of the method parameter.

I see no harm in declaring a method parameter 'final', but I'm generally a fan
of verbosity in Java programming anyway. People who don't like it call it
"noise", but universally without justifying the epithet in engineering terms.
Is it "noise" if it enforces non-assignment, which the very critics of 'final'
seem to find an error?

The impact is low enough that I recommend to code reviewers to enforce
consistency rather than one practice or the other. If an author's default is
to declare 'final', let them Javadoc when they omit it, and vice versa.

Even though I might know the right answer, if the cost is low and the benefit
likewise there's greater reward in cooperation than correctness.