What you guys seem to be missing is that there is absolutely no state space gain to be had between the scenarios:
Variable 'foo' will hold either "A" or "B", but not anything else, and: there are two variables, 'foo' and 'fooNormalized'. It becomes even worse when you realize that virtually all modification of parameter out there consists of the form: Variable 'foo' is A in the preamble of the method, and 'B' everywhere else, vs: there are two variables. Less variables is just as much of a nice-to-have as limited state space. On Feb 13, 9:45 pm, Casper Bang <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
