Casper Bang wrote: > I like final on parameters as well as local variables (a final > parameter is just a local variable pushed from a lower stack frame). > While realizing it is no guarantee for immutability, it helps me > feeling more in control of the exposed state space, remember to add > pre-conditions and generally yields better™ code. A Java anno 2009 > would surely use opt-in non-final semantics no? > I don't understand the argument. Java is pass by value so the value on the stack can't be changed and that is all final would protect anyways.
Regards, Kirk > Happy weekend > /Casper > > > On 13 Feb., 19:09, Reinier Zwitserloot <[email protected]> wrote: > >> This is a spin-off from the 'code reviews' thread (http:// >> groups.google.com/group/javaposse/browse_thread/thread/ >> 827d3257c903e9bd/35db9fd36906dd5d#35db9fd36906dd5d ) >> >> Robert Fischer isn't the first soul I've heard mention that they >> either enforce setting all parameters to 'final', or, because that >> created ginormous method signatures, configure their IDE to warn/error >> when parameters are modified. >> >> I wonder if this really is a good idea. >> >> The usual arguments come in three flavours, at least as far as I've >> heard them: >> >> 1. The confusion argument: java is strictly pass-by-value so >> someParameter = x; does NOT change the meaning of 'someParameter' in >> the code that called your method. By disallowing assignment you avoid >> the confusion (This is Robert's argument). >> >> 2. The overlook argument: As methods grow larger (or even if they >> remain small and you're just glancing) you may miss a re-assignment to >> a parameter, and as you add some code onto the end of a method, for >> example to fix a bug, you erroneously think the value has been >> untouched. Proponents of this argument also usually enforce that >> 'return' must be the last statement, under the presumption that a mid- >> method return may let people think that the code they just added to >> the end is always run before the method returns normally. >> >> 3. The save-the-value argument: You never know when you need to >> original value that was passed in, so changing it may require >> refactors down the line. >> >> They all seem like bullpucky to me though. Point-by-point >> deconstruction: >> >> 1. If you're going to make rules because your fellow programmers don't >> know their arse from their teakettles, you'll never get anything done. >> Sure, for extremely obscure stuff I can see some value in setting up >> style checkers and the like to disallow certain operations, but >> something as simple as pass-by-value? Also, even if you really do have >> such mythically stupid programmers, you can still catch them in their >> error: Anybody that changes any local variable or parameter and then >> never touches it again is clearly doing SOMETHING wrong (that >> assignment was a no-op!), and if someone makes the mistake of thinking >> that java is pass-by-reference, they'll hit that sooner rather than >> later. javac doesn't check for this, but findbugs does. In fact, I >> think that most methods that would only work if java is pass-by-ref >> will make this mistake. >> >> 2. You can't just shove code into a method without understanding the >> method first. For example, I've seen lots of methods that take their >> incoming parameter, and then perform a normalization on it; for >> example, an incoming string gets a if ( x == null ) x = ""; treatment >> so future code can treat null and the empty string the same. Any >> casual method editor probably THINKS they are working on the >> normalized version. By enforcing the original coder to come up with a >> second variable to hold the normalized version, you're actually >> creating the very situation you tried to avoid! >> >> 3. ... then why don't you refactor it? We have refactor tools for a >> reason. >> >> I have a soft (meaning: feel free to break it if you have a decent >> reason to do so) rule regarding changing your method parameters: >> >> Make all changes to all parameters before the real meat of the method >> begins. Then, consider them final. (In other words, if you want to >> replace a parameter being 'null' with a default, or expand an input >> with a prefix, or any other normalization, do so at the very top of >> the method, then never change it again). >> >> Unfortunately there's no tool out there that has a rule to check if >> you adhere to it. >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
