I like to use final on passed-in parameters, but not always. The reason I find it valuable is for those rare situations, where I want to make a point to whoever is looking at the implementation of the method that a particular parameter is subject to mutability due to the way the method is implemented. Just a little hint to help make sense of the code.
Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net --- On Fri, 2/13/09, Casper Bang <[email protected]> wrote: > From: Casper Bang <[email protected]> > Subject: [The Java Posse] Re: 'final' mandatory on parameters? > To: "The Java Posse" <[email protected]> > Date: Friday, February 13, 2009, 1:59 PM > 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 -~----------~----~----~----~------~----~------~--~---
