Casper Bang 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. >
Unnecessary verbage IMHO. Regards, Kirk > /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 -~----------~----~----~----~------~----~------~--~---
