Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Curious compiler warning Date: Sat, 21 Jan 2012 12:13:22 -0800 Organization: albasani.net Lines: 75 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 0Qz50e25JzynzWOV0DpP43XE321S6Rg1XkzqSvdjpHcXY1KgNZ2T6Swj8om1YSIhKLVhNk5cCxnoxsxM4udrsrYUjxnYO0PkB6EdAXgBpH+JqpcG+zrL2+2KkpCEJ611 NNTP-Posting-Date: Sat, 21 Jan 2012 20:13:23 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="Z23a+DnRyU2P4XML6RvTlYz0hjiTYcBRy6xPTr1RVIcPSKm9nfhX+R+eiEu3shv8sjWsidrZClUgXorfOvUfCaeNaDx5830+/clDt/wWvp7xMvc77KUri0fiNunZ9oLC"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 In-Reply-To: Cancel-Lock: sha1:aOv573SJ5VMojrtzsLQC4beBWGc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:11568 Wanja Gayk wrote: > 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: >> http://www.adam-bien.com/roller/abien/entry/final_method_parameters_should_generate > > (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. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg