> 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.
So you are saying that just because you know the original value can't be changed, you see no incentive to limit its state space? My point was more as to treat each and every local variable the same, less to go into a value/ref/in/out debate. At the end of the day, final serves as much for documentation as anything else since it's not part of the signature nor bytecode. /Casper > > 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 -~----------~----~----~----~------~----~------~--~---
