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