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?
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 -~----------~----~----~----~------~----~------~--~---
